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ABSTRACT 


A  student  team  at  the  Naval  Postgraduate  School  studied  the  need  for,  and 
development  of,  a  system  that  effectively  and  economically  deters  piracy  in  an  area  of 
interest.  The  systenT's  proposed  area  of  operation  is  the  Gulf  of  Aden,  but  the  system 
may  be  deployed  to  any  operational  theater  where  piracy  threatens  maritime  commerce. 
Piracy  and  hijacking  of  ships  off  the  Somali  Coast  have  grown  tenfold  since  2006.  In 
response  to  this  growing  problem,  the  U.S.  Navy,  along  its  with  allies,  formed  Combined 
Task  Force  151  (CTF-151)  to  protect  approximately  33,000  merchant  vessels  transiting 
through  this  area  daily.  CTF-151  patrols  the  Internationally  Recommended  Transit 
Corridor  (IRTC)  in  the  Gulf  of  Aden  and  because  of  this,  Somali  pirates  have  begun  to 
migrate  away  from  the  IRTC  and  CTF-151  patrols.  For  this  reason,  the  team  studied  the 
use  of  UAV  technology  that  allowed  for  broader  area  of  piracy  surveillance  and 
detection.  The  system  that  was  conceived  and  analyzed  was  the  Oceanic  Armed 
Reconnaissance  System  (OARS).  The  OARS  Basic  alternative,  when  analyzed  against 
CTF-151,  was  found  to  be  the  most  cost  effective  system.  This  OARS  Basic  system  is 
comprised  of  a  Littoral  Combat  Ship  (LCS)  as  a  host  vessel,  ScanEagle  UAVs,  an  SH-60 
Helicopter,  and  Zodiac  Rigid  Hulled  Inflatable  Boats  (RHIB). 
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EXECUTIVE  SUMMARY 


Piracy  and  hijacking  of  ships  off  the  Somali  Coast  has  increased  drastically  over 
the  last  five  years.  In  an  attempt  to  counter  these  pirate  acts  and  provide  friendly  cargo 
vessels  with  safe  passage  through  the  Gulf  of  Aden,  the  U.S.  Navy,  along  with  its  allies, 
formed  Combined  Task  Force  151  (CTF-151).  This  task  force  provides  safe  passage  for 
cargo  vessels  by  patrolling  a  narrow  strip  of  the  Gulf  of  Aden,  called  the  Internationally 
Recommended  Transit  Corridor  (IRTC).  CTF-151'^  presence  along  the  IRTC  has  driven 
pirates  further  away  into  other  areas  of  the  Gulf  of  Aden  and  the  Indian  Ocean. 

As  Systems  Engineering  students  studying  at  the  Naval  Postgraduate  School,  this 
problem  was  brought  to  our  attention  and  became  the  focal  point  of  our  research.  The 
need  for  an  anti-piracy  system  with  a  larger  area  of  coverage  became  evident.  From  this 
need,  our  team  decided  to  investigate  the  use  of  Unmanned  Aerial  Vehicle  (UAV) 
technology  to  aid  in  covering  a  larger  area  of  ocean.  The  system  that  was  conceived  and 
analyzed  was  called  the  Oceanic  Armed  Reconnaissance  System  (OARS). 

At  the  end  of  our  research  and  analysis,  the  system  that  was  found  to  be  the  most 
cost  effective  in  regards  to  piracy  detection  and  deterrence  was  the  “OARS  Basic” 
alternative.  The  subsystem  components  that  comprise  OARS  Basic  are  a  Littoral  Combat 
Ship  (LCS),  ScanEagle  UAVs,  an  SH-60  Helicopter,  and  Zodiac  Rigid  Hulled  Inflatable 
Boats  (RHIB).  Performance  of  six  of  these  OARS  Basic  systems  were  compared  against 
the  current  CTF-151ships. 

Our  research  team  began  our  work  by  first  outlining  the  scope  of  the  problem  and 
by  researching  current  technology.  After  outlining  the  scope  of  the  problem  and 
conducting  a  technology  feasibility  analysis,  our  team  then  developed  a  concept  of 
operations  (CONOPs)  for  two  different  OARS  variations,  OARS  Basic  and  OARS 
Augmented.  These  concepts  included  the  use  of  an  array  of  existing  UAV  technology, 
which  would  be  integrated  into  a  host  vessel  platform.  Besides  being  used  for 
surveillance  and  reconnaissance,  the  UAVs  will  also  collect  live-video  of  pirate  activity, 
which  will  provide  stronger  evidence  in  court  for  convicting  pirates  of  crimes. 
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The  goal  of  the  host  vessel  was  to  provide  surveillance  and  interdiction  of  pirate 
activity,  which  could  be  supplemented  with  pursuit  and  interdiction  craft,  such  as  RHIBs 
and  helicopters.  The  OARS  Augmented  alternative  included  everything  from  the  Basic 
OARS  alternative,  but  also  utilized  a  long  range  airship  or  Broad  Area  Maritime 
Surveillance  (BAMS)  UAV  to  increase  detection  and  surveillance  potential.  The 
feasibility  of  these  systems  was  supplemented  by  information  from  subject  matter  experts 
and  stakeholders. 

The  team  conducted  a  House  of  Quality  (HOQ)  analysis  to  quantify  which  design 
characteristics  were  most  critical  to  the  stakeholders.  The  team  determined  that  Detect 
and  Track  were  the  most  valuable  design  characteristic,  as  indicated  from  the  associated 
weighted  metrics.  To  gauge  the  effectiveness  of  these  design  characteristics  during 
OARS  system  modeling  and  design,  twelve  Key  Performance  Parameters  (KPPs)  were 
selected  from  a  pre-determined  list  of  Measures  of  Performance  (MOPs).  Some  of  these 
KPPs  included  percent  of  pirate  detection,  coverage  area,  intercept  time,  and  number  of 
engagements.  These  twelve  KPPs  became  the  test  metrics  for  system  comparison  during 
the  modeling  and  simulation  phase. 

After  the  functional  and  physical  architectures  had  been  derived,  the  team 
generated  seven  alternatives  for  physical  OARS  systems.  These  seven  alternatives  were 
comprised  of  different  combinations  of  OARS  subsystems.  Each  alternative  outlined 
specific  guns,  missiles,  communication  systems,  radars,  sensor  equipment,  vessels, 
helicopters,  and  UAVs,  all  of  which  are  currently  mature  systems.  In  an  effort  to 
facilitate  rapid  deployment  and  reduced  cost,  only  existing  warfare  systems  with  high 
technology  readiness  level  (TRL)  were  considered  as  subsystem  variants.  The  critical 
variants  considered  in  this  process  were  the  host  vessel,  helicopter,  pursuit  vessel,  and 
UAV. 

The  emergent  preferred  alternative,  which  we  deemed  as  “OARS  Basic,” 
incorporated  the  use  of  an  LCS  host  vessel,  a  SH-60  helicopter,  Zodiac  RHIBs  as  pursuit 
vessels,  and  ScanEagle  UAVs.  The  team  also  indicated  a  second  alternative,  referred  to 
as  “Augmented  OARS,”  which  incorporated  a  BAMS  UAV  for  additional  aerial 
surveillance. 
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Using  these  two  identified  alternatives,  OARS  Basic  and  Augmented  OARS,  the 
team  built  models  of  each  and  simulated  their  operations  using  the  Naval  Simulation 
System  (NSS)  software.  Each  scenario  contained  the  same  environmental  modeling 
parameters,  which  consisted  of:  355  transiting  cargo  vessels,  100  pirate  motherships,  and 
200  pirate  skiffs.  The  model  environments  spanned  390,000  square  miles  of  ocean  in  the 
Gulf  of  Aden  and  simulated  anti -piracy  operations  during  a  30  day  period.  During  data 
analysis,  the  team  focused  on  particular  NSS  data  measurements  which  were  relevant  to 
original  stakeholder  MOEs.  OARS  Basic  proved  to  be  slightly  more  capable  of 
neutralizing  and  deterring  pirate  motherships,  while  also  detecting  35%  more  pirates  than 
CTF-151.  This  is  attributed  to  the  fact  that  OARS  Basic  had  four  times  more  airborne 
UAVs  than  CTF-151  and  suggests  that  simply  the  presence  of  UAVs  deters  pirate 
activity. 

During  the  last  week  of  modeling  and  simulation  runs,  the  OARS  team"s 
modeling  and  simulation  databases  were  inadvertently  erased.  This  resulted  in  the  loss  of 
all  software  models  and  prohibited  the  OARS  team  from  extracting  the  modeling  results 
of  the  OARS  Augmented  alternative.  For  this  reason,  CTF-151  was  only  compared 
against  the  OARS  Basic  alternative. 

The  cost  analysis  showed  that  OARS  Basic  has  a  Life  Cycle  Cost  (LCC)  of 
$15. 5B,  which  is  12%  cheaper  than  CTF-151"s  LCC  of  $17. 5B.  Using  these  LCCs  and 
the  effectiveness  results  from  the  modeling  and  simulation  analysis,  the  OARS  team 
recommends  the  OARS  Basic  alternative  to  be  utilized  in  future  anti-piracy  missions. 
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I. 


INTRODUCTION 


A.  OBJECTIVE 

The  objective  of  this  project  was  to  develop  a  system  that  effectively  and 
economically  deters  piracy  in  an  area  of  interest.  The  systenf's  current  area  of  operation 
is  the  Gulf  of  Aden,  but  the  system  may  be  deployed  to  any  operational  theater  where 
piracy  threatens  maritime  commerce. 

B.  BACKGROUND 

Piracy  has  re-emerged  as  a  problem  to  the  international  maritime  community. 
Piracy  is  a  worldwide  concern  for  all  vessels  traveling  the  open  seas.  Piracy  is  defined  as 
consisting  of: 

“  ...any  of  several  acts,  including  any  illegal  act  of  violence  or  detention, 
or  any  act  of  depredation,  committed  for  private  ends  by  the  crew  or  the 
passengers  of  a  private  ship  and  directed  against  another  ship,  aircraft, 
persons,  or  property  onboard  another  ship  on  the  high  seas;  or  against  a 
ship,  persons  or  property  in  a  place  outside  the  jurisdiction  of  any  state  ” 
(Maritime  Security:  Actions  Needed  to  Assess  and  Update  Plan...,  GAO 
2011). 

Although  piracy  could  happen  anywhere  across  the  global  seas,  piracy  near  the  shores  of 
Somalia,  including  the  Gulf  of  Aden,  Southern  Somalia  Basin,  and  Western  Indian 
Ocean,  has  grown  in  staggering  proportion  over  the  last  five  years.  Table  1  illustrates  the 
growing  numbers  of  Somalia  based  pirate  attacks  over  the  last  5  years  (United  States 
General  Accountability  Office  (GAO),  "Maritime  Security:  Updating  U.S.  Counterpiracy 
Action  Plan. . .  2011).  In  2006,  Somali  Piracy  accounted  for  only  9%  of  the  global  piracy 
attempts.  Today,  Somali  Piracy  accounts  for  over  60%  of  the  worldwide  total  pirate 
attempts  (International  Maritime  Bureau,  2011). 

Modem  day  pirates  are  usually  armed  with  very  intimidating  weaponry,  including 

long  knives,  AK-47  assault  rifles,  and  Rocket  Propelled  Grenades  (RPGs).  Somali  pirates 

are  not  centrally  controlled,  but  have  a  common  mission.  That  mission  is  to  hijack  high 

value  ships,  hold  the  crew  members  hostage,  and  extort  millions  of  dollars  in  ransom 

money.  Hundreds  of  attacks  are  recorded  each  year.  Pirates  have  captured  dozens  of 
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ships,  held  thousands  of  hostages,  and  have  cost  the  maritime  community  severely  in 
losses  and  spent  revenue  (IMB  Piracy  Report  2010-201 1). 

Pirates  utilize  motherships  and  smaller  skiffs  to  commit  piracy  acts.  The 
motherships  can  be  any  large  vessel,  including  fishing  vessels,  yachts,  or  large  industrial 
vessels  that  have  recently  been  hijacked.  When  a  target  vessel  is  spotted,  the  pirates 
launch  the  smaller  skiffs  and  proceed  to  board  and  hijack  the  vessel.  Pirate  skiffs  usually 
carry  between  four  and  eight  passengers,  can  have  twin  out-board  engines,  contain  large 
quantities  of  fuel,  and  often  contain  ladders  and  grappling  hooks  for  boarding. 
Depending  on  the  victim  vessel,  pirates  can  board  and  take  over  a  vessel  in  less  than  20 
minutes  (GAO,  “Maritime  Security:  Updating  U.S.  Counterpiracy  Action  Plan,  2011). 

1.  Current  Anti-Piracy  Solutions 

The  Combined  Task  Force  151  (CTF-151)  is  currently  deployed  within  the  Gulf 
of  Aden  to  combat  piracy.  CTF-151  is  a  multinational  task  force  that  was  established  in 
2009  to  conduct  counter-piracy  operations.  In  the  Gulf  of  Aden,  CTF-151  patrols  the 
Internationally  Recommended  Transit  Corridor  (IRTC).  The  IRTC  is  a  narrow  passage 
way  through  the  Gulf  of  Aden  that  was  created  after  piracy  escalated  in  the  area 
(Combined  Maritime  Forces  2011).  The  IRTC  allows  CTF-151  to  concentrate  its  patrols 
and  has  helped  to  deter  some  piracy  in  the  Gulf  of  Aden,  but  unfortunately,  piracy  still 
remains  a  threat  to  everyone  who  transits  near  the  Horn  of  Africa.  CTF-151  patrols  the 
IRTC  and  even  escorts  merchant  vessels  from  time  to  time.  However,  most  of  CTF- 
151"s  anti-piracy  operations  are  initiated  by  distress  calls  from  merchant  vessels  that  are 
already  being  attacked  by  pirates. 

2.  Current  Limitations  to  Combating  Somali  Piracy 

What  makes  Somali  Piracy  difficult  to  counter  is  the  pirates"  lack  of  definitive 
characteristics  that  separate  them  from  the  fishermen  and  civilians.  The  fact  is  that  most 
Somali  pirates  are  ex-fishermen  and  operate  on  fishing  vessels.  The  Horn  of  Africa, 
especially  within  the  Gulf  of  Aden,  is  a  very  popular  fishing  area  to  the  natives.  This 
means  that  there  are  a  multitude  of  innocent  fishing  vessels  in  the  area,  which  makes  it 
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very  difficult  for  anyone  to  identify  pirates  before  they  actually  commit  a  crime 
(Christensen  2009). 

Another  downside  to  effectively  combating  piracy  is  the  maritime  legal 
restrictions  placed  upon  naval  forces  when  facing  pirates. 

“A  state  of  war  does  not  exist  therefore  the  law  of  armed  conflict  does  not 
apply  -  pirates  cannot  be  targeted  as  if  they  were  combatants.  Force  can 
only  be  used  against  pirates  in  either  self-defense  /  defense  of  others  or  to 
stop  the  vessel  in  order  to  board  it  -  its  use  must  be  avoided  as  far  as 
possible  and,  where  unavoidable,  must  not  go  beyond  what  is  reasonable 
and  necessary  in  the  circumstances  ’’  (Christensen  2009). 

This  makes  it  difficult  to  stop  piracy  in  its  tracks.  Even  when  a  distress  call  is 
received  and  the  pirates  are  intercepted  by  CTF-151,  it  is  hard  to  collect  incriminating 
evidence  against  the  pirates  to  convict  them  of  any  crimes.  This  is  due  to  the  fact  that 
pirates  will  often  throw  their  paraphernalia  (weapons,  ladders,  ammunition,  etc.) 
overboard  if  they  spot  CTF-151  naval  vessels. 


3.  UAV  Technology  in  the  Deterrence  of  Piracy 

In  order  to  combat  these  deficiencies,  the  OARS  Capstone  team  pursued  the  use 
of  UAV  technology  in  anti-piracy  operations.  The  use  of  UAV  technology  in  anti-piracy 
operations  will  allow  for: 

•  A  broader  area  of  surveillance  coverage.  This  allows  the  OARS  system  to 
be  easily  transferable  to  other  pirate-infested  waters,  and  ultimately, 
anywhere  in  the  world  where  piracy  is  an  issue. 

•  A  better  source  of  video-footage  and  imagery  of  pirate  vessels.  These 
images  and  video  surveillance  can  be  used  as  incriminating  evidence 
against  the  pirates  to  ensure  that  when  caught,  they  will  serve  jail  time  for 
their  intentions  and  not  just  be  “caught  and  released,”  as  is  the  current 
norm.  Even  though  it  is  often  difficult  to  determine  whether  or  not  a 
vessel  is  a  pirate  vessel,  there  are  some  tell-tale  signs  that  the  UAVs  can 
search  for  that  can  aid  in  determining  suspicious  vessels.  These  are:  long 
ladders,  large  quantities  of  fuel  drums,  guns  and  ammunition  crates,  and 
large  quantities  of  men  (upwards  of  8  to  10  men  in  a  single  small  skiff). 

•  An  ever-present  “eye  in  the  sky”  mentality  that  will  keep  the  pirates 
always  looking  over  their  shoulder.  The  fact  that  the  pirates  know  that 
they  could  be  under  surveillance  at  any  given  time  by  UAVs  will  make 
them  less  willing  to  commit  acts  of  piracy. 
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C.  SCOPE  AND  ASSUMPTIONS 

1.  Scope 

Pirates  use  a  flexible  mode  of  operation  and  operate  in  an  area  that  spans 
hundreds  of  square  miles.  They  can  lay  dormant  in  an  area  for  weeks  or  attack  almost 
daily  against  any  ship  within  their  range. 

Due  to  its  large  concentration  of  ship  traffic  and  its  proximity  to  the  Somali  coast 
line,  the  Gulf  of  Aden  has  been  the  main  focus  of  Somali  piracy  attempts.  Table  1  shows 
the  number  of  piracy  attempts  that  are  attributed  to  Somali  Pirates. 


Table  1.  Locations  of  All  Attempted  and  Actual  Somalia  Piracy  Acts  from 
2006  to  2011  (From  IMB  Piracy  Report,  2010-2011). 


Locations 

2006 

2007 

2008 

2009 

2010 

2011  (Jan - 
June, 

6  months) 

Somalia 

10 

31 

19 

80 

139 

125 

Gulf  of  Aden 

10 

13 

92 

117 

53 

20 

Red  Sea 

15 

25 

18 

REST  OF  Arabian  Sea 

2 

4 

1 

2 

WORLD  Indian  Ocean 

1 

Oman 

3 

4 

Yearly  Totals  of  SOMALIAN  PIRATE 
Attacks/Attempts 

22 

51 

111 

218 

219 

163 

Yearly  Totals  of  WORLDWIDE 
Attacks/Attempts 

239 

263 

293 

410 

445 

266 

Percentage  of  SOMALIAN  PIRATE 
Attacks  vs.  the  WORLD  WIDE  Totals 

9% 

19% 

38% 

53% 

49% 

61% 

Due  to  the  fact  that  the  Gulf  of  Aden  is  a  natural  chokepoint  and  that  over  33,000 
ships  transit  its  waters  every  year,  the  OARS  team  focused  on  prevention  of  piracy  within 
the  Gulf  of  Aden  (GAO,  "Maritime  Security:  Updating  U.S.  Counterpiracy  Action  Plan, 
2011). 
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2.  Assumptions 

To  meet  such  a  challenge,  the  OARS  team  developed  the  following  list  of  initial 
system  needs  and  assumptions: 

The  OARS  system  should: 

•  Focus  on  the  Gulf  of  Aden  similar  to  CTF- 1 5 1 . 

•  Adhere  to  the  Navy"s  Seapower-21  concept  and  its  net-centric  maritime 
domain  awareness  doctrine. 

•  Be  deployable  by  2020  and  capable  of  defending  all  shipping  from  piracy, 
within  the  current  1.1  million  square  mile  operational  area  of  CTF-151. 

•  Be  capable  of  neutralizing  pirates  and  then  arresting,  detaining  & 
maintaining  evidence  for  continued  prosecution. 

•  Be  developed  jointly  with  international  interests. 

•  Be  supportable  by  current  DoD  logistics  systems. 

•  Have  increased  use  of  ship  borne  UAV  platforms  (Off  the  shelf  UAVs, 
where  any  modifications  would  be  limited). 

•  Utilize  non  lethal  UAV  deterrence  (Where  pirates  will  get  the  message  but 
not  be  killed). 

•  Comply  with  International  Law. 

•  Developed  as  cost  effectively  as  possible. 

D.  SYSTEMS  ENGINEERING  METHODOLOGY  AND  APPROACH 

The  OARS  system  engineering  process  consisted  of  Mission  Conceptualization, 
Concept  of  Operations,  Requirements  Analysis,  System  Development,  System  Analysis, 
System  Verification,  System  Integration,  and  Recommendations. 

The  OARS  team  utilized  the  systems  engineering  “Vee”  diagram  as  a  guideline 
for  creating  a  tailored  system  engineering  process.  The  classic  “Vee”  was  then  adapted 
to  fit  our  unique  anti-piracy  mission,  to  meet  the  need  for  early  mission  development,  to 
be  consistent  with  our  capstone  schedule,  and  to  meet  the  goals  and  focus  of  our 
Modeling  and  Simulation  effort.  Figure  1  illustrates  the  OARS  systems  engineering 
process  (Buede  2009,  Ch.  1). 


5 


The  schedule  of  our  capstone  project  consisted  of  three  academic  quarters  of 
work,  with  a  main  reporting  milestone  at  the  end  of  each  quarter  (each  quarter  consisted 
of  approximately  three  months).  These  milestones  were  the  In  Progress  Review  (IPR) 
#1,  IPR  #2,  and  the  Final  Brief.  Both  of  the  IPRs  were  presentations  where  our  team 
briefed  our  current  progress,  findings,  and  path  forward,  to  our  project  advisors, 
stakeholders,  classmates,  and  other  NPS  faculty.  The  Final  Brief  was  a  presentation  that 
summarized  all  of  our  work,  conclusions,  and  recommendations.  Due  to  the  fact  that  our 
work  was  divided  by  three  distinct  milestones,  we  divided  our  systems  engineering 
approach  into  three  distinct  sections,  as  shown  in  Figure  1. 

The  three  different  color  shades  display  the  specific  areas  of  work  that  were  to  be 
completed  or  in-process  by  each  milestone  IPR.  The  green  arrows  show  the  feed  forward 
requirements  of  the  process.  The  blue  arrows  show  the  feedback  loops  in  the  system  as 
the  system  was  developed,  requirements  were  found,  and  the  teanf's  knowledge  of  the 
subject  area  grew.  The  black  diamonds  displayed  are  the  major  milestone  reviews  that 
were  completed  at  each  stage  of  the  system  development.  The  elements  of  the  system 
design  were  reiterated  in  place,  to  transform  the  piracy  threat  from  a  nebulous  series  of 
issues  to  a  definable,  model-able,  and  scalable  solution  (Maier  and  Rechtin  2009,  Ch.  1). 

1.  Mission  Conceptualization 

The  Mission  Conceptualization  block  contained  the  effort  to  define  the 
operational  requirements  for  the  system  and  to  validate  the  feasibility  of  those 
requirements.  The  block  consisted  of  the  mission  development,  operational 
requirements,  and  feasibility  analysis.  The  mission  development  was  the  teanf's  initial 
work  and  starting  point  for  a  concept  to  meet  the  piracy  threat.  This  was  done  to  identify 
and  mitigate  possible  team  biases  for  the  deployment  of  the  system.  Such  biases  included 
an  overdependence  on  airship  technologies,  and  a  preference  for  the  Broad  Area 


6 


I  PR#  1 


Mission  Conceptualization 

Mission  Development 

Operational  Requirements 

Feasibility  Analysis 

Concept  of  Operations 

initial  Trade  Study 

Operational  Concept 

I  PR  #2 


Requirements  Analysis 

Problem  Definition 

Assumptions 

Stakeholder  Analysis 

Mission  scope 

Context  Boundary 

Measure  of  Effectiveness 

|  Key  Performance  Pa 

r  a  meters  | 

ITR 


System  Development 


System  Architecture 


Allocated  Architecture 


Functional  Architecture 


Physical  Architecture 


Sub-System  Development 


Z 


ASR 


System  Analysis 

Modehng  and  Simulation 

Alternative  Analysis 

Risk  Analysis 

Cost  Analysis 

SRR 


I  PR  #3 


System  Verification 

Modeling  and  Simulation 

Stakeholder  Feedback 

T  &  E  Planning 

System  Integration 


Component  int. 


Sub  System  l nt. 


integration  Review 


^  SFR 


Recommendations 


Final  Presentation 


Final  Report 


Figure  1.  OARS  System  Engineering  Process 
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Maritime  Surveillance  (BAMS)  Unmanned  Aerial  Support  (UAS)  system.  The 
operational  requirements  listed  the  possible  environments  and  situations  the  system 
would  be  expected  to  encounter,  such  as  the  Gulf  of  Aden  environment.  The  Feasibility 
Analysis  set  the  limits  of  the  system  to  coincide  with  the  timeframe,  cost,  and  technology 
maturity  of  the  possible  system  solution.  Although  this  step  did  not  finalize  a  list  of 
requirements,  it  set  the  framework  for  the  requirements  analysis,  and  the  development  of 
the  Concept  of  Operation  (CONOPS)  for  the  OARS  system. 

2.  Concept  of  Operations 

The  CONOPS  phase  was  completed  concurrently  with  the  requirements  analysis, 
and  detailed  the  process  by  which  the  needs  and  stakeholder  requirements  became  crafted 
around  a  material  solution,  the  idea  being  that  the  only  solutions  that  cannot  be  used  are 
the  ones  that  are  never  considered.  The  initial  trade  study  listed  all  possible  solutions  that 
could  have  been  used  to  meet  the  mission  framework  and  requirements.  With  a  defined 
list  of  possible  solutions,  the  trade  study  compared  each  by  current  manufacturing 
capabilities,  technology  readiness  levels  (TRL),  and  subject  matter  expertise.  This 
allowed  the  team  to  narrow  down  the  field  of  possible  solutions.  The  operational  concept 
now  defined  the  size,  scope,  location,  and  functions  of  the  system. 

3.  Requirements  Analysis 

The  Requirements  Analysis  phase  was  an  ongoing  and  iterative  process  that 
sought  to  refine  the  piracy  problem  from  a  nebulous  series  of  wants  and  issues  to  a 
measureable,  quantifiable  set  of  mission  performance  parameters.  This  process  started 
with  a  formal,  stakeholder-reviewed  problem  definition  and  was  bound  by  the 
assumptions  needed  to  define  the  problem.  A  thorough  stakeholder  analysis  listed  the 
operators,  military  personnel,  concurrent  system  representatives,  and  contractor  support. 
With  stakeholder  feedback,  a  mission  scope  was  developed  to  meet  the  problem 
definition. 
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4.  System  Development 

The  System  Development  phase  of  the  SE  process  resulted  in  the  creation  of  the 
OARS  System  Architecture.  The  System  Architecture  started  to  take  shape  as  the  formal 
CONOPS  model,  the  objective  hierarchy,  and  the  functional  hierarchy  evolved. 

The  team  conducted  a  House  of  Quality  (HOQ)  analysis  to  quantify  which  design 
characteristics  were  most  critical  to  the  stakeholders.  The  team  determined  that  “Detect” 
and  “Track”  were  the  most  valuable  design  characteristic,  as  indicated  from  the 
associated  weighted  metrics.  To  gauge  the  effectiveness  of  these  design  characteristics 
during  OARS  system  modeling  and  design,  twelve  Key  Performance  Parameters  (KPPs) 
were  selected  from  a  pre-determined  list  of  Measures  of  Performance  (MOPs).  Some  of 
these  KPPs  included  percent  of  pirate  detection,  coverage  area,  intercept  time,  and 
number  of  engagements.  These  twelve  KPPs  became  the  test  metrics  for  system 
comparison  during  the  modeling  and  simulation  phase. 

After  the  MOPs  and  KPPs  were  defined,  a  functional  architecture  was  derived  to 
meet  these  objectives.  With  the  functional  architecture  developed,  the  Functional 
Allocation  step  mapped  the  systenf's  functions  to  a  corresponding  physical  element  under 
the  CONOPS.  This  resulted  in  the  physical  architecture.  After  the  allocated  architecture, 
physical  architecture,  and  functional  architecture  were  finalized,  the  overarching  system 
architecture  for  the  OARS  system  was  defined.  This  system  architecture  was  then  further 
decomposed  into  the  sub-system  components  of  the  OARS  architecture.  The  key 
stakeholders  were  then  consulted  and  their  feedback  was  implemented  back  into  the 
design  of  the  OARS  system.  A  finalized  version  of  the  OARS  concept  was  honed  in 
upon,  and  a  process  and  strategy  for  its  testing  and  evaluation  began. 

5.  System  Analysis 

The  System  Analysis  phase  consisted  of  initial  Modeling  and  Simulation  (M&S) 
efforts,  risk  analysis,  and  cost  estimation  calculations.  Although  the  overarching  OARS 
system  had  been  refined,  the  elements,  components,  and  additional  solutions  were 
compared  with  these  processes.  During  this  phase,  the  two  OARS  alternatives,  OARS 
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Basic  and  OARS  Augmented,  were  weighed  and  scored  against  the  status  quo  on  a  basis 
of  mission  performance,  feasibility,  cost,  and  risk. 

6.  System  Verification 

The  System  Verification  process  contained  robust  Modeling  and  Simulation 
scenarios  from  which  the  alternatives  were  modeled  and  analyzed  further.  Using  the  two 
identified  alternatives,  OARS  Basic  and  Augmented  OARS,  the  team  built  models  of 
each  and  simulated  their  operations  using  the  Naval  Simulation  System  (NSS)  software. 
Each  scenario  contained  the  same  environmental  modeling  parameters,  which  consisted 
of:  355  transiting  cargo  vessels,  100  pirate  motherships,  and  200  pirate  skiffs.  The  model 
environments  spanned  390,000  square  miles  of  ocean  in  the  Gulf  of  Aden  and  simulated 
anti-piracy  operations  during  a  30  day  period. 

During  the  System  Verification  phase,  the  team  focused  on  particular  NSS  data 
measurements  which  were  relevant  to  original  stakeholder  MOEs,  such  as,  percent  of 
pirate  detection,  number  of  successful  pirate  attacks,  and  number  of  engagements. 


7.  System  Integration 

The  System  Integration  phase  of  the  systems  engineering  process  defined  an 
integration  strategy  for  the  OARS  system.  The  team  analyzed  each  subsystem  that  make 
up  an  OARS  system.  From  there,  the  interoperability  of  each  subsystem  was  checked 
against  the  other  subsystems  to  determine  if  they  could  be  integrated.  This  was  done  by 
conducting  research  of  the  subsystems  and  their  corresponding  support  systems,  as  well 
as  consulting  with  the  subsystem"^  Subject  Matter  Experts  (SME).  One  example  of  an 
integration  concern  was  whether  or  not  the  host  vessel  could  support  multiple  UAVs, 
their  launch  platforms,  and  control  stations. 

8.  Recommendations 

Finally,  the  Recommendations  phase  of  the  systems  engineering  process  was 
where  the  OARS  team  computed  all  findings  from  the  previous  phases  and  made 
recommendations  for  the  most  efficient  and  cost  effective  system,  as  well  as 
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recommendations  for  areas  of  further  study.  Based  on  life  cycle  costs  and  the 
effectiveness  results  from  the  modeling  and  simulation  analysis,  the  OARS  team 
recommended  the  OARS  Basic  alternative  to  be  utilized  in  future  anti-piracy  missions. 
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II.  PROBLEM  DEFINITION 


Focusing  on  the  Requirements  Analysis  Block  of  the  SE  design  process,  the 
OARS  team  adopted  a  multi-objective  approach  for  defining  the  best  system  with  regard 
to  stakeholder  needs.  The  following  chapter  transforms  the  OARS  team"s  stakeholder 
inputs  and  requirements  analysis  effort  into  the  CONOPS  that  is  used  as  the  basis  of  the 
systenf's  design. 

A.  PROBLEM  STATEMENT 

Global  piracy  has  progressively  increased  over  the  last  four  years,  significantly 
impacting  maritime  commerce  and  burdening  international  maritime  navies.  Due  to 
CTF-151"s  efforts  of  patrolling  the  IRTC,  the  piracy  problem  has  began  to  spread  to  a 
larger  ocean  environment.  The  problem  is  to  comprehensively  survey  and  protect  a  vast 
amount  of  ocean.  Additionally,  Somali  pirates  are  hard  to  identify  from  normal 
fishermen,  so  a  capability  needs  to  exist  to  allow  for  classification  of  pirates  before  they 
attack. 

The  OARS  system  will  attempt  to  deter  piracy  in  a  vast  area  of  open  ocean  by 
providing  UAV  surveillance  and  reconnaissance.  The  OARS  systenf's  UAV  technology 
will  attempt  to  classify  pirates  before  they  attack.  Once  pirates  have  been  identified,  the 
system  should  be  capable  of  neutralizing  and  detaining  the  pirates. 

B.  REQUIREMENTS  ANALYSIS 

Requirements  are  generally  considered  the  cornerstone  of  the  systems  engineering 
process.  Originating  requirements  are  those  requirements  initially  established  by  the 
system  stakeholders,  with  the  help  of  the  systems  engineering  team.  Some  examples  of 
originating  requirements  for  the  OARS  system  were  the  requirements  for  capturing  of 
live-video  surveillance  of  pirate  activity  and  the  requirement  that  UAVs  should  not  use 
lethal  force.  The  systems  engineering  design  process  is  a  mixture  of  establishing 
requirements  to  define  the  design  problem  and  portioning  the  physical  resources  of  the 
system  into  components  that  perform  functions  that  meet  the  requirements.  Many 
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important  decisions  are  made  by  the  systems  engineering  team  that  will  ultimately  affect 
the  performance  of  the  system  and  the  satisfaction  of  the  stakeholders  (Buede  2009). 


1.  Stakeholder  Analysis 

A  stakeholder  analysis  was  conducted  to  gain  a  better  understanding  of  the  needed 
capability  and  determine  customer  desires  from  a  larger  point  of  view,  with  the  goal  of 
addressing  joint,  international  and  naval  service  requirements. 

The  fundamental  need  was  framed  as  the  next  upgrade  using  a  system  approach  to 
a  piracy  suppression  mission.  The  team  conducted  stakeholder  analysis  to  create  a  list  of 
needs  and  desires  from  an  emerging  list  of  stakeholders.  Information  was  gathered  by 
conducting  interviews  via  email,  phone  calls  and  telephone  conferencing.  The  questions 
were  designed  to  guide  the  stakeholder  through  the  difficult  issues  the  OARS  team 
discovered  during  their  research.  Follow-on  discussions  were  teleconferenced  with 
willing  stakeholders  who  offered  time  to  discuss  their  needs,  requirements  and  concerns 
regarding  an  OARS  System. 

The  OARS  team  was  initially  evaluating  the  use  of  lethal  deterrence  aboard  the 
UAVs,  but  the  results  of  the  stakeholder  analysis  indicated  that  this  was  a  bad  idea  as  it 
would  not  comply  with  international  maritime  law.  For  this  reason,  the  UAVs  were  only 
used  for  surveillance  and  reconnaissance. 

a.  Stakeholders 

The  stakeholders  who  had  a  vested  interest  were  identified  from  the 
following  groups  of  policy  and  decision-makers:  Fleet  Commands,  users,  acquisition 
agents,  developers,  engineering  contractors  and  Test  and  Evaluation  (T&E)  analysts.  The 
key  stakeholders  for  this  undertaking  were  determined  to  include,  but  are  not  limited  to 
the  following: 
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Table  2.  Primary  Stakeholders. 


Stakeholder 

Category 

Organization 

Name 

Title/Role 

DoD/U.S. 

United  States  Navy 

CAPT  Richard 

Brown 

Executive  Assistant  to 
the  Assistant  Secretary 
of  the  Navy 

United  States  Navy 

LT  David  Cook 

Riverine  Squadron  Three 

Naval  Postgraduate  School 

David  Place,  CAPT 
USN  Retired 

UAS  Fleet  Liaison 

International/ Joint 

International  Crime 

Service  Maritime  Bureau 

Cyrus  Moody 

Manager 

Ohio  Airships 

Robert  Rist 

Engineer 

Airship  Consultant 

Joe  Bloggs 

Consultant 

Hawker  Beechcraft 

Tim  Schow 

Engineer 

UAV  Industry 

Tomorrow  Aerospace 

Shobhit  Mehrotra 

Lead  Structural  and 

Control  Engineer 

Aereon  Corporation 

William  McE. 

Miller 

President  and  CEO 

NRL  Monterey,  CA 

Dr.  James  Hansen 

PARS  SME 

b.  Fleet  Commands 

The  Fifth  Fleet  has  an  interest  in  developing  a  solution  to  the  hostile 
actions  of  pirates  directed  at  shipping  placed  under  their  protection.  Their  involvement 
with  the  SE  process  was  the  most  influential  due  to  the  sponsor-like  relationship  fleet 
commands  have  with  sponsor  funding. 

c.  User  Representatives 

The  naval  vessels  engaged  with  CTF-151  operations  have  been  operating 
for  two  to  three  years.  A  Naval  Ship  Commanding  Officer  who  commanded  the  USS 
Gettysburg  during  one  assignment  to  this  region  provided  invaluable  points  of  view  on  a 
variety  of  issues  related  to  user  operations,  such  as  the  boarding  of  pirate  mothership  and 
the  capturing  of  prisoners. 

A  Fast  Boat  Commanding  Officer  (CO)  with  responsibilities  to  develop 
tactics  for  preventing  hostile  boardings  and  attacks  upon  commercial  vessels  in  the 
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western  Arabian  Sea  and  Gulf  of  Aden  provided  critical  resources  to  OARS.  One  point 
that  he  made  very  clear  was  that  the  early  identification  of  pirates  was  very  important  as 
it  made  the  boarding  party  much  safer.  This  Commanding  Officer  had  developed, 
trained,  and  provided  logistic  planning  requirements  that  enabled  inbound  naval  forces  to 
field  combat-ready  forces. 

Additional  stakeholder  input  was  provided  to  our  project  by  the  Director 
of  the  Pirate  Attack  Risk  Surface  (PARS)  effort  at  the  Naval  Research  Lab  located  in 
Monterey,  CA.  The  PARS  Software  is  a  predictive  model  that  utilizes  algorithms  to  try 
and  predict  the  likelihood  of  an  attack  by  pirates.  Due  to  its  classification,  actual  PARS 
data  was  not  used  in  our  Modeling  and  Simulation  efforts. 

d.  System  Developers 

A  number  of  UAV  industry  contacts  were  helpful  and  interested  in  the 
OARS  effort.  These  stakeholders  included  companies  such  as  Ohio  Airships  Incorporated 
(Akron,  OH),  Airship  Consultant  (Shortstown,  Bedfordshire,  England),  Hawker 
Beechcraft  Corporation  (Witchita,  Kansas),  and  Aereon  Corporation  (Princeton,  New 
Jersey).  These  experienced  contractors  provided  inputs  for  the  interface  design  and 
communication  strategy.  One  of  the  areas  that  they  aided  us  in  was  how  to  operate 
multiple  UAVs  from  a  single  host  vessel. 

2.  Stakeholder  Feedback 

Stakeholder  solicitation  was  accomplished  by  conducting  surveys  and  interviews 
with  our  stakeholders,  as  well  as  researching  the  current  solution  and  difficulties 
experienced  in  anti-piracy  operations.  Questions  were  designed  to  facilitate  effective 
telephone  interviews  with  stakeholders.  The  problem  statement  was  formed  from  the 
inputs  gathered  from  all  stakeholder  groups.  A  summary  of  key  stakeholder  inputs  can 
be  found  in  Appendix  A. 
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a.  Policy  Makers  ’  Recommendations 

Research  of  operations  policy  documents  offered  insight  into  the 
operational  capability  of  maritime  patrolling.  Based  in  Manama,  Bahrain,  the  Fifth  Fleet 
approved  and  funded  the  current  CTF-151  efforts,  which  are  limited  to  the  oceanic 
choke-points  in  the  Gulf  of  Aden  where  pirate  activities  had  been  reported  and  observed. 
The  policy  guidance  for  the  maritime  effort  demanded  a  system  traceable  back  to  the 
following  naval  capability  requirements: 

•  Forces  will  use  multi-channel  two-way  C2/SA  systems  that  protect  data  at 
the  confidential  or  higher  level  of  classification.  All  devices  operated  at 
this  level  that  transmit  and  receive  voice  and  video  data  will  be  designed 
to  protect  this  data  to  a  level  merited  by  classified  information. 

•  Data  collected  from  the  UAV  systems  will  allow  the  dual  use  of  UHF  and 
Satellite  distribution  networks  to  provide  un-interrupted  delivery  of  real¬ 
time  information  for  on-scene  commanders  to  conduct  multi-sensor 
patrols.  These  patrols  will  conduct  around  the  clock  in  all  weather 
conditions  to  allow  maximum  probability  of  hostile  detection  within  the 
operational  area  assigned. 

•  Blue  Force  support  vessels  will  provide  additional  afloat 
services  as  required  to  conduct  internationally  supported  INTERPOL 
certificated  activities.  UAV  units  operating  in  an  operation  space  will 
employ  capabilities  that  allow  assets  to  deploy  and  retrieve  on  a  host 
vessel  for  the  purpose  of  refueling  and  servicing  multiple  detection  and 
data  transmission  equipment. 

•  Blue  Force  Commanders  will  provide  necessary  direction  to  Multi-system 
operations  in  a  coordinated  manner  with  one  Common  Operational  Picture 
(COP). 

b.  Acquisition  Agent  Recommendations 

Interview  responses  from  acquisition  community  members  offered 
understanding  about  the  early-milestone  preferences  of  today"s  acquisition  workforce. 
The  following  were  recommendations  from  the  acquisition  agents: 

•  Develop  an  Initial  Capability  Document  (ICD)  for  OARS. 

•  Create  a  formal  Program  Objective  Memorandum  (POM)  initiative  for 
OARS. 

•  Continue  dialogue  with  the  operational  forces  to  identify  evolving  needs. 

•  Continue  socializing  the  concept  to  U.  S.  Navy  leadership. 
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•  Develop  Capability  Development  Documents  (CDDs)  to  identify  the 
highest  priority  required  capabilities  as  determined  by  the  warfighter 
input. 


c.  Clients  and  Users  Recommendations 

Interview  responses  from  the  user  community  offered  insight  to  the 
preferences  of  today"s  solution,  and  provided  feedback  on  additional  capabilities  desired 
by  the  end-user.  The  current  force  capability  fielded  has  communication  systems  (secure 
and  clear),  recording  devices  for  evidence  collection,  command  and  coordination  chain  of 
command,  and  gun  weapon  systems  (major  and  minor  caliber).  Some  foreign  ships  have 
medium  caliber  guns. 

The  following  desired  capabilities  were  identified  by  the  users: 

•  Tracking  of  suspicious  shipping  in  transit  channels  where  Blue  Cargo 
vessels  pass. 

•  Situational  awareness  of  Blue  Forces  in  the  transit  channels. 

•  Communication  connection  to  the  OARS  command  center. 

•  Secure  and  unsecure  communications. 

•  Logistical  support  plan. 

•  Data  sharing  to  support  the  COP. 

•  Interoperability  between  coalition,  service  elements,  and  other  agencies 
for  joint  missions. 

•  Ruggedized  equipment  with  enhanced  durability  for  the  different 
operational  environments  experienced. 

•  Ease  of  use  and  ergonomics  for  primary  search  sensors. 

7.  Needs  Analysis 

The  results  of  the  OARS  teanf's  research  and  interviews  with  key  stakeholders 
enabled  the  requirements  development  to  progress  with  a  rich  data  set.  However  an 
independent  detail  analysis  of  the  problem  was  needed  to  further  constrain  and  define  the 
problem.  Every  pirate  attack  that  occurred  in  the  Gulf  of  Aden  during  2010  and  the  first 
quarter  of  2011  was  recorded  by  the  ICC  Piracy  and  Robberies  report.  The  team 
cataloged  and  analyzed  this  data  to  further  define  the  piracy  problem  and  develop  the 
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performance  parameters  of  the  system.  Figure  2  shows  the  highlights  of  the  team"s  data 
analysis.  The  team  derived  values  for  the  50th  percentile  and  the  maximum  percentile  for 
metrics  such  as;  distances  between  pirate  attacks,  hours  between  pirate  attacks,  speed  of 
attacks,  and  areas  covered  by  the  pirates.  The  chart  illustrates  the  values  of  the  distance 
between  attacks  and  hours  between  attacks.  It  then  compares  the  operating  range 
between  these  attacks.  The  team  assumed  the  effect  to  be  linear  and  this  led  to  the  range, 
endurance,  and  area  covered  metrics.  The  metrics  were  derived  to  cover  the  majority  of 
attacks  in  an  area  of  1.1  square  million  miles.  The  pie  chart  that  is  located  in  the  lower 
left  comer  of  Figure  2  shows  the  type  of  attacks  the  pirates  have  committed.  It  shows 
that  all  attacks  occur  when  ships  are  underway.  The  last  chart  shows  the  number  of 
attacks  per  season,  and  illustrates  that  the  attacks  are  dependent  on  weather  and  sea  state. 
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Figure  2.  OARS  Affinity  Diagram. 
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8.  Effective  Needs  Statement 

Discussions  with  stakeholders  allowed  the  team  to  formulize  a  chain  of  events 
that  must  be  followed  by  the  OARS  system  in  order  to  effectively  counter  piracy.  It  was 
identified  that  the  first  action  that  must  occur  is  the  “detection”  of  pirates.  Once  detected, 
the  OARS  system  must  maintain  “tracking”  of  those  pirates.  The  OARS  system  must 
then  be  able  to  “intercept”  the  pirates.  And  finally,  the  OARS  system  must  be  able  to 
“neutralize”  the  pirates  by  disarming  them  and  making  arrests.  The  team  also  made  the 
decision  that  this  system  would  be  designed  to  be  as  cost  effective  as  possible.  And  do  to 
the  fact  that  the  system  will  be  operating  in  International  waters,  the  system  must  also 
comply  with  International  Maritime  Law. 

Following  a  full  examination  of  stakeholder  requirements,  the  results  of  the  needs 
analysis,  and  the  OARS  team''s  original  assumptions  that  were  documented  in  Section  C 
of  Chapter  I,  the  following  effective  needs  statement  was  derived: 

The  OARS  system  will  economically  and  efficiently  detect,  track,  intercept,  and 

neutralize  pirate  threats  across  1.1  million  square  miles  of  open  ocean,  within 

compliance  with  international  maritime  law. 

9.  Input-Output  Model 

In  Figure  3  the  OARS  team  developed  a  simple  view  of  the  inputs  and  outputs  of 
the  system  at  the  top  system  level.  This  view  provides  a  partial  list  of  controllable  and 
uncontrollable  inputs  and  their  respective  outputs  after  the  system  while  operating.  This 
list  was  not  all  inclusive  but  is  a  partially  focused  set  of  considerations  based  on  the 
existing  CTF-151  system  used  today  and  considered  essential  for  operations. 
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Controlled  Inputs 

Expected  Outputs 

♦Area  of  Initial  Search 

♦Efficient  Data  Collection  (Tracking) 

♦Optimum  Search  Space 

&  Identification 

•Operation  Orders 

•Criminal  Activity  Interdiction 

♦TTP’s 

•Orderly  Processing  of  Pirates  and 

♦Network  Interfaces  for  Shared  Data 

Evidence 

•Ready  Condition  Assets,  i.e.,  RHIBs 

•Decreased  Number  of  Pirate 

&  Support  Ship  Availability 

Attacks 

INPUTS 

OARS  System 

OUTPUTS 

Uncontrolled  Inputs 

Possible  Stochastic  Events 

•Environmental  Conditions 

•Pirates  Board  Commercial  Vessel 

•Electronic  Emission  Conditions 

•Commercial  Crew  Kidnapped 

•Hostile  Red  Force  Tactics, 

•Commercial  Crew  Member  Killed 

Techniques,  and  Practices 

•Military  Crew  Member  Kidnapped 

•Weather/Environment 

♦Military  Crew  Member  Killed 

•Communication  Failures 

♦Military  Asset  Damaged 

•Numerous  Casualties  Needing  Aid 

Figure  3.  OARS  Input/Output  Model 


a.  Controllable  Inputs: 

The  operators  have  the  ability  to  select  one  operating  area  in  the  most 
probable  intercept  position.  The  random  probability  of  the  hostile  intrusion  was  modeled 
through  the  Naval  Simulation  System  (NSS)  software  to  forge  the  environment  of  space 
and  time  attached  to  the  goal  of  response  and  prevention  of  boarding. 

The  material  requirements  were  in  the  form  of  seagoing  systems  deployed 
now  for  monitoring  events  at  sea  in  an  area  of  interest  by  U.  S.  Naval  forces  in  keeping 
with  common  operating  Tactics,  Techniques  and  Procedures  (TTPs).  The  physical 
boundaries  of  the  system  were  supported  with  common  maintenance  approaches  used  by 
deployed  units. 

Data  sets  with  formatted  descriptive  elements,  such  as  Operational  Orders, 
were  provided  via  common  secure  communications  and  issued  by  appropriate  Blue  Force 
Commanders.  Risk  mitigation  plans  and  procedures  were  pre-planned  to  accommodate 
hazards  and  eventualities  that  were  considered  to  challenge  the  integrity  of  primary 
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mission  objectives.  For  the  purposes  of  this  project,  it  was  assumed  that  these  C2/SA 
devices  will  interface  with  a  network  capable  radio/transmission  device. 

Additional  information  systems  relying  on  an  available  network  capable 
system  did  include  automated  Weapons  Systems  Status,  Individual  Health  Monitoring, 
and  other  systems  reporting  details  relevant  to  the  operating  environment.  Inputs  were 
processed  via  networking  interfaces  like  Universal  Serial  Bus  (USB),  Ethernet,  and  Serial 
ports. 


b.  Uncontrollable  Inputs: 

With  all  operational  systems,  the  uncontrollable  inputs  consisted  of 
networking  anomalies,  environmentally  destructive  effects,  electromagnetic  effects,  and 
equipment  failures.  Our  SE  process  considered  a  variety  of  opportunities  to  create 
harmful  eventualities  during  operations,  in  hopes  of  designing  so  as  to  mitigate  or  prevent 
failure  events. 


c.  Controllable  Outputs: 

Outputs  were  enabled  via  networking  interfaces.  As  a  result  of  timely 
communications  and  detection  processes,  the  ability  to  develop  and  analyze  data  in  a 
patrolling  at-sea  environment  allowed  naval  assets  to  search,  detect,  track,  and  target 
contacts  with  a  variety  of  on-vessel  controlled  sensors.  Actionable  information  through 
visual  images  of  ships  and  activities  at  sea  in  daylight  and  low  light  level  periods  were 
viewed  and  shared  with  a  command  and  control  center.  The  data  sent  from  the  system  to 
a  shared  network  provided  the  best  picture  of  situational  awareness  that  was  possible 
under  the  mechanical,  electrical  and  stochastic  conditions.  The  system  provided  services 
in  response  to  developed  situations  that  demanded  specialized  resources  like  weapon 
systems  on  RHIBs  and  medical  services  following  the  use  of  lethal  force.  Additional 
services  like  detention  and  transportation  of  criminal  suspects,  seized  property,  and 
contraband  were  provided. 
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d.  Uncontrollable  Outputs: 

Some  of  the  uncontrollable  outputs  that  can  have  a  negative  effect  on  ship¬ 
board  operations  were  identified  as;  cross-talking  circuits,  network  interruptions,  garbled 
or  unreadable  data,  and  other  data  elements.  The  system  was  able  to  overcome  these 
obstacles  through  redundancy  and  sound  communication  procedures.  The  failed 
processing  of  data  allows  corrupted  data  to  be  considered  as  actionable  data  necessary  to 
be  placed  in  context  and  used  appropriately  despite  error  and  inconsistency.  The  system 
was  robust  enough  that  such  weakness  in  command  and  control  offered  opportunity  to 
dismiss  unreliable  data. 

The  10  model  in  Figure  3  provided  the  SE  Team  another  tool  that 
described  the  basic  information  flow  of  data  and  the  basic  functions  expected  within  the 
communications  /networks/weapons  system  at  the  top  level.  In  other  words,  the  team 
used  the  10  model  to  determine,  “What  does  the  system  need  to  do?”  rather  than  try  to 
resolve  „How  does  the  system  do  it?"  The  description  of  the  system  then  allowed  the 
team  to  move  forward  into  the  functional  analysis. 

C.  CONCEPT  OF  OPERATIONS  (CONOPS) 

1.  Current  Anti-Piracy  Operations  (CTF-151) 

Current  anti-piracy  operations  consist  of  Combined  Task  Force  151  (CTF-151) 
operating  in  the  Gulf  of  Aden  and  the  surrounding  area.  CTF-151  is  comprised  of  a  mix 
of  U.S.  Navy  ships  and  coalition  ships  commanded  by  a  rotating  command  post.  The 
ships  are  assigned  individual  patrol  areas  that  patrol  the  entire  region  on  a  twenty-four 
hour  basis.  Ships  are  assigned  individual  patrol  regions  which  are  designed  to  maximize 
the  amount  of  area  covered  based  on  current  information  on  suspected  pirate  activity. 
When  a  distress  call  is  received,  the  nearest  CTF-151  ship  responds.  When  the  U.S. 
Navy  or  coalition  ship  is  within  acceptable  helicopter  range,  a  helicopter  is  deployed  to 
provide  immediate  assistance  to  the  merchant  vessel.  At  that  time,  the  helicopter  may 
also  start  to  gather  on-site  intelligence,  which  is  then  relayed  back  to  the  commander  on 
board  the  ship.  The  helicopter  is  not  allowed  to  automatically  engage  the  suspected 
pirates  unless  in  self-defense.  Helicopters  are  allowed  to  use  intimidation  tactics  to  deter 
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suspected  pirates.  If  suspected  pirates  do  not  stop,  the  attack  helicopter  pilots  are  allowed 
to  ask  commanders  for  a  “weapons  free”  order  which  allows  them  to  utilize  the  small 
caliber  machine  guns  to  fire  in  front  of  or  behind  the  suspected  pirates  for  further 
intimidation  tactics.  When  suspected  pirates  have  stopped,  RHIBs  are  deployed  from  the 
ship  to  capture  prisoners  and  evidence  for  eventual  prosecution.  RHIB  boats  are  lightly 
manned  and  equipped  with  personal  small  arms,  although  they  are  only  utilized  for  self- 
defense  purposes.  Figure  4  shows  an  Operational  Concept  diagram  of  the  CTF-151 
solution.  Since  CTF-151  is  comprised  of  many  different  vessels  from  many  different 
countries,  its  Operational  Concept  includes  a  plethora  of  naval  vessels.  The  concept 
diagram  depicts  all  elements  involved  in  a  CTF-151  mission  including  naval  vessels, 
helicopters,  container  ships,  RHIBs,  and  satellite  communications.  The  background  of 
the  diagram  is  a  depiction  of  the  Gulf  of  Aden  and  Indian  Ocean  with  markers  indicating 
where  acts  of  piracy  occurred  in  2010. 


TufSay  Fniiz*  Dtitroy* 


Figure  4.  Operational  Concept:  Current  Solution,  CTF-151. 
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Some  ships  that  are  not  equipped  with  a  helicopter  may  employ  an  UAV  that 
performs  reconnaissance  missions  on  suspected  pirates.  Suspected  pirate  motherships  are 
difficult  to  distinguish  from  ordinary  harmless  fishing  vessels  and  vessels  containing 
people  and  arms  with  the  intent  of  capturing  unarmed  merchant  vessels.  The  UAV 
provides  real-time,  up-close,  video  surveillance  of  the  suspected  pirates. 


2.  OARS  CONOPS  Generation 

The  requirements  analysis  phase  of  the  systems  engineering  process  led  the 
OARS  team  to  develop  multiple  alternative  systems.  The  stakeholders  were  very  clear  on 
the  needs  of  the  OARS  anti-piracy  system.  These  needs  were  focused  around  the 
particular  need  for  a  system  that  could  cover  a  broad  area  of  ocean,  due  to  the  fact  that 
Somali  Pirates  are  expanding  their  reach  into  the  Indian  Ocean  and  beyond.  For  this 
reason,  the  OARS  team  sought  to  create  a  system  that  utilized  unmanned  aerial  vehicles 
(UAV)  that  would  be  launched  from  “host  vessels”  at  sea. 

The  purpose  of  the  host  vessel  is  to  provide  a  resource  from  which  to  launch, 
recover  and  support  the  UAVs.  The  area  of  operation  about  the  host  vessel  will  be 
defined  by  the  most  effective  and  efficient  use  of  a  number  of  UAV  craft  to  provide 
assistance  to  all  vessels  in  peril  within  a  reasonable  time  period.  The  sensors  will  detect 
and  communicate  video  and  location  data  such  that  critical  tracking  will  have  occurred  in 
determining  the  identification  of  a  target  of  interest. 

The  elements  of  the  OARS  system  are:  Host  vessel,  UAVs,  helicopters,  satellite 
networks,  pursuit  vessels,  and  targets.  The  OARS  system  has  a  fixed  number  of  UAVs 
that  perform  detection,  surveillance,  tracking,  identification,  and  communication  of  data. 
These  UAVs  have  been  proven  to  operate  well  in  all  expected  weather  conditions.  The 
winds  are  generally  below  17  knots  and  gale  winds  develop  in  the  more  eastern  oceanic 
areas  from  the  Horn  of  Africa  up  to  40  knots.  The  temperatures  were  generally  hot  year- 
round  with  temperatures  routinely  exceeding  90  degrees. 
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a.  Basic  OARS 

The  OARS  Basic  CONOPS  model  includes  a  ship  capable  of  supporting 
multiple  swarms  of  UAV  operations,  armed  helicopter  operations,  all  net-centric  C4I 
requirements,  brig  capabilities  for  transportation  of  captured  pirates,  as  well  as  weapons 
for  self-defense.  Pursuit  vessels  are  also  required  to  capture  pirates  once  they  have  been 
detected.  Figure  5  represents  an  Operational  Concept  diagram  for  OARS  Basic.  The 
green  radar  circles  represent  individual  search  area  range. 


Container  ship 


Figure  5.  Operational  Concept:  OARS  Basic. 

As  mentioned  in  Chapter  1  of  this  report,  the  OARS  team  focused  on 
protecting  the  entire  Gulf  of  Aden  from  piracy.  For  this  reason,  six  individual  OARS 
Basic  systems  will  be  strategically  placed  in  the  Gulf  of  Aden.  Figure  6  illustrates  the 
area  of  coverage  that  would  be  achieved  by  six  Basic  OARS  systems. 
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- 1 000  Cargo  Ships  per  Month  (500  coming  1 

-  Scaneagle  Mission  1 8  Hours  @  45  Knots 

-  9  Scaneagles  i 

-Model  #Scaneagles  needed  for  95%  detection  (Assdm^tion:  when  detected  they  are  deterred) 

-  Primary  MOE:  >=  95%  of  all  Cargo  Ships  make  it  through  in  a  month 
-Secondary  MOE:  >=  95%  pirate  detection  r 
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Figure  6.  Six  OARS  Basic  Systems  Placed  Within  the  Gulf  of  Aden. 
b.  Augmented  OARS 

The  last  CONOPS  option  includes  everything  from  the  Basic  OARS 
model,  plus  an  augmentation  using  a  high  altitude  long  range  airship  such  as  the  Broad 
Area  Maritime  Surveillance  (BAMS)  UAV.  This  will  supplement  the  coverage  area 
provided  by  the  Basic  OARS  model  which  uses  much  slower  ship-launched  UAVs.  The 
BAMS  UAVs  will  be  land-based  and  located  wherever  the  OARS  commander  deems 
necessary  based  to  the  perceived  threat.  The  Augmented  OARS  Operational  Concept 
diagram  is  shown  in  Figure  7. 
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Container  ship 


Figure  7.  Operational  Concept:  OARS  Augmented. 

Just  as  with  the  Basic  OARS  CONOPS,  the  Augmented  OARS  CONOPS 
will  also  feature  six  identical  OARS  systems  to  allow  for  complete  coverage  of  the  Gulf 
of  Aden  transit  corridors.  Figure  8  illustrates  the  area  of  coverage  that  would  be  achieved 
by  utilizing  six  Augmented  OARS  Systems  in  the  Gulf  of  Aden.  The  large  oval-shaped 
area  that  is  colored  “green”  on  the  figure  illustrates  the  added  search  pattern  that  would 
be  gained  from  the  BAMS  UAV  or  Airship. 
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-  1000  Cargo  Ships  per  Month  (500  coming  fron 

-  Scaneaale  Mission  18  Hours  @  45  Knots 

-  9  Scaneaales 

-Model  #Scaneagles  needed  for  95%  detection  (Assumption:  when  detected  they  are  deterred) 

-  Primary  MOE:  >=  95%  of  all  Cargo  Ships  make  it  trough  in  a  month 
-Secondary  MOE:  >=  95%  pirate  detection  ra 
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Figure  8.  Six  Augmented  OARS  Systems  Placed  Within  the  Gulf  of  Aden. 
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III.  DESIGN 


The  Design  and  Analysis  of  the  OARS  system  provides  a  solution  space  for  the 
problem  definition,  primitive  needs,  refined  requirements,  and  stakeholder"^  interest.  It 
combines  elements  of  the  Requirements  Analysis,  System  Development,  and  System 
Analysis  stage  of  the  System  Engineering  process.  It  also  helps  to  develop  the  inputs  and 
alternatives  for  the  modeling  and  simulation  needed  for  the  final  result.  The  Design  and 
Analysis  stage  begins  with  the  system  requirements  and  refines  the  customer  needs 
through  the  House  of  Quality  (HOQ).  It  maps  the  requirements  through  the  functional 
analysis  into  a  possible  architecture.  With  the  elements  of  the  architecture  known,  sub¬ 
system  alternatives  are  generated  and  screened  by  feasibility.  It  then  details 
recommended  alternatives  for  the  modeling  and  simulation  (Blanchard  and  Fabrycky 
2006,  Ch.  2  and  3). 

A.  SYSTEM  REQUIREMENTS 

The  system  requirements  are  the  actions  and  processes  that  the  OARS  system  is  to 
complete,  which  are  usually  articulated  in  “shall”  statements.  They  are  divided  into  two 
separate  groups,  functional  and  non-functional  requirements.  The  Functional 
Requirements  are  the  requirements  that  the  OARS  system  is  to  complete  by  performing 
the  functions  and  actions  necessary  to  solve  the  problem  definition  and  mitigate  pirate 
threats  within  its  context  boundary.  The  Non-functional  requirements  are  those 
requirements  that  support  the  completion  of  the  functional  requirements.  These  included 
the  suitability  requirements,  such  as  reliability,  maintainability,  and  usability. 

1.  Functional  Requirements 

The  functional  requirements  are  the  actions  and  functions  that  the  OARS  system 
must  carry  out  to  deter  piracy  and  protect  shipping  in  its  area  of  operation.  As  defined  by 
the  effective  needs  statement,  the  OARS  system  must  detect,  track,  intercept,  and 
neutralize  threats  within  compliance  of  maritime  law.  In  order  to  accomplish  this,  the 
OARS  system  must  carry  out  a  mission  defined  by  the  mission's  functions.  These 
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mission  functions  are  to  start  a  mission,  patrol  an  area,  communicate,  engage  hostiles  if 
detected,  and  finally,  to  return  to  port  when  the  mission  is  complete.  These  functions  are 
illustrated  in  Figure  9. 


MISSION  START  PATROL 


COMMUNICATE  _ Detect.  Fix/Classify, 


Return  to  Port  Intercept,  Neutralize 


Figure  9.  OARS  Mission  Profile. 

Each  of  these  mission  functional  requirements  are  needed  to  complete  an  OARS 
mission.  The  team  created  these  mission  functions  to  simplify  the  OARS  mission  profile, 
while  still  keeping  in  mind  the  needs  of  the  OARS  system.  Table  3  shows  how  the  needs 
statement,  which  was  derived  in  Chapter  II,  correlates  to  the  OARS  mission  profile. 
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Table  3.  Needs  Statement  Mapping  to  Mission  Functions. 


Need 

Statement 

Functions 

Mission 

Start 

Patrol 

Communicate 

Engage 

Ho  stiles 

Mission 

End 

Detect 

X 

X 

X 

Track 

X 

X 

X 

Intercept 

X 

X 

X 

Neutralize 

X 

X 

Within 

Compliance 

X 

X 

X 

X 

X 

The  Mission  Start  function  detailed  all  aspects  of  preparation,  logistics,  and 
movement  to  place  the  OARS  system  in  the  theater  of  operation.  The  Patrol  aspect  of  the 
mission  included  the  actions  required  to  patrol  an  area  of  suspected  pirate  activity, 
including  the  Detect,  Track,  and  Intercept  functions.  The  Communicate  function 
encompasses  all  communication  efforts  between  the  OARS  system  and  allied  vessels, 
friendly  cargo  vessels,  UAVs,  etc.  On  encounter  with  a  group  of  pirates,  the  Engage 
Hostile  requirement  included  all  of  the  requirements  needed  to  intercept  and  neutralize 
hostile  targets.  Once  the  mission  has  been  completed,  the  Mission  End  aspect  covered  all 
the  actions  needed  to  return  the  assets  and  personnel  to  their  home  stations  and  prepare 
the  physical  systems  for  the  next  deployment  required  to  fulfill  the  functions  previously 
stated.  These  top  level  functions  were  developed  to  meet  the  objective  requirements  and 
were  traced  down  to  the  performance  parameters  needed  to  carry  out  the  mission. 

2.  Non-Functional  Requirements 

The  Non-Functional  Requirements  are  all  the  requirements  necessary  for 
continued  operations  of  the  OARS  system  as  it  carries  out  its  mission.  Non-functional 
requirements  are  the  mission  critical  requirements  that  cannot  be  deduced  from  direct 

examination  of  the  piracy  threat  but  are  inherent  in  the  system.  For  example,  the 

33 


reliability  of  the  system  helps  to  determine  the  operational  availability  of  the  sub¬ 
systems.  This  also  helps  to  determine  the  required  number  of  critical  spares  and  the 
number  of  OARS  systems  that  are  actually  needed.  The  Human  Factors  requirement  of 
the  system  determines  the  operational  man  power  requirements  and  determines  the  crew 
sizing  per  each  OARS  system.  These  non-functional  requirements  are  typically  found 
using  “bottom-up  analysis”  techniques,  which  are  techniques  of  tracing  the  requirements 
backwards  after  the  system  has  been  developed.  Because  the  OARS  team  focused  on 
UAV  technology  in  the  deterrence  of  piracy,  the  non-functional  requirements  were 
addressed  briefly  by  the  team  in  a  top-level  analysis,  leaving  these  particular 
requirements  as  an  area  for  future  research. 

B.  OBJECTIVE  REQUIREMENTS 

1.  Measures  of  Effectiveness  (MOE) 

The  objective  requirements,  which  consist  of  Detect,  Track,  Intercept,  Neutralize, 
and  Compliance  with  international  maritime  law,  are  broken  down  into  function  layers 
and  are  ultimately  transformed  into  the  systenT's  physical  architecture.  The  customer 
needs  are  based  on  a  modified  kill  chain  used  by  U.S.  Military  forces.  The  top-level  of 
the  OARS  system  included  Detect,  Track,  Intercept,  Neutralize,  and  Comply  with 
international  maritime  law.  The  Detect  stage  was  critical  since  this  has  been  a  continuing 
problem  in  anti-piracy  operations.  Often  it  is  not  until  the  pirates  have  engaged  a  neutral 
target  that  they  are  even  considered  suspicious.  Once  a  possible  pirate  target  has  been 
found,  the  OARS  system  had  to  track  the  target  to  determine  its  course  and  its  intention. 
The  stakeholders  have  stated  that  finding  sufficient  evidence  to  prosecute  the  pirates 
remains  a  high  priority  for  the  system. 

The  next  function  of  the  OARS  system  was  to  intercept,  or  cause  interception  of 
the  threat.  This  will  force  the  adversary  to  reconsider  their  actions  or  ultimately  be 
arrested.  The  last  function  was  to  neutralize  the  pirate  threats.  This  could  be 
accomplished  through  detaining  the  pirates,  showing  force,  or  the  actual  use  of  this  force. 
All  the  functions  must  be  conducted  within  the  scope  of  maritime  law,  within  the 
boundaries  of  a  basic  regard  for  the  human  rights  of  the  pirates,  as  well  as  the  norms  and 
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regulations  found  in  the  Geneva  Convention  and  the  Uniform  Code  of  Military  Justice. 
Below  these  five  top-level  functional  requirements,  the  detailed  functions  of  the  system 
fully  define  the  mission  and  what  actions  need  to  take  place  to  fulfill  it.  The  customer"s 
needs  are  mapped  to  the  objective  requirements.  These  are  then  met  by  the  functions  of 
the  systems,  which  are  mapped  to  the  physical  architecture  and  computed  into  a 
measureable  aspect  by  the  Measures  of  Effectiveness  (MOE).  The  MOEs  are  then 
derived  from  a  physical  metric  by  the  performance  parameters.  To  meet  the  performance 
parameters,  the  derived  requirements  are  found  to  determine  the  physical  needs  and 
requirements  of  the  system.  Since  the  OARS  Capstone  project  was  a  top-level  effort,  the 
derived  requirements  from  the  performance  parameters  were  not  calculated. 

To  ensure  that  the  requirements  flow-down  was  within  line  with  stakeholder 
expectations  and  to  make  sure  that  the  key  requirements  were  properly  weighted,  an 
Analytic  Hierarchy  Process  (AHP)  was  used  to  assign  customer  preference  to  the 
appropriate  functions.  This  was  the  start  of  the  Quality  Function  Deployment  (QFD) 
Analysis  (Buede  2009,  Ch.  6). 

C.  QUALITY  FUNCTION  DEPLOYMENT  (QFD) 

The  QFD  aids  the  stakeholder  in  assuring  that  the  most  critical  requirement 
receives  the  greatest  consideration.  Design  is  a  balance  of  compromises  between 
competing  goals.  QFD  assures  that  the  stakeholder'^  goals  and  the  systenf's  strengths  are 
aligned.  The  first  step  is  to  weigh  the  stakeholder'^  needs  against  one  another  in  order  to 
highlight  the  greatest  needs.  The  OARS  mission  statement  is  to  economically  and 
efficiently  detect,  track,  intercept  and  neutralize  pirate  threats  across  1.1  million  square 
miles  of  Open  Ocean,  within  compliance  with  International  Maritime  Law.  Each  of  these 
needs  are  dependent  upon  each  other  and  critical  to  the  mission  statement.  Figure  10 
shows  which  mission  aspects  were  most  critical  in  the  eyes  of  the  stakeholders.  The 
strongest  relationship  among  the  needs  of  the  OARS  system  was  the  relationship  between 
Detect  and  Intercept  (Blanchard  and  Fabrycky  2006,  Ch.  3). 
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Criteria 

Criteria 

Detect 

Track 

Intercept 

Neutralize 

Compliance  with  International 

Law 

- 

♦ 

in 

Weights 

Detect 

1 

2.5 

1.5 

3 

3.5 

0.3723 

Track 

2 

0.4 

i-i-i-:: 

0.6 

1.2 

1.4 

0.1489 

Intercept 

3 

0.8887 

1.8887 

: : :  :t :  i  * 

2 

2.3333 

0.2482 

Neutralize 

4 

0.3333 

0.8333 

0.5 

:  i :  i  \ :  \ 

1.1667 

0.1241 

Compliance  with  International  Law 

5 

0.2857 

0.7143 

0.4286 

0.8571 

0.1064 

Figure  10.  Preference  Weights  of  the  Stakeholder'^  Needs. 


The  QFD  process  was  implemented  through  a  series  of  interconnecting  HOQ 
matrices.  This  portion  of  the  process  begins  by  listing  the  customer  needs  down  the  left 
side  of  a  matrix,  as  shown  in  the  left-most  rows  of  the  AHP  in  Figure  11.  After  the 
customer'^  needs  were  listed,  their  corresponding  rankings  are  then  listed  in  the  next 
column  to  the  right.  These  rows  are  collectively  referred  to  as  the  WHATS  of  the  HOQ. 
The  columns  are  the  technical  response  of  the  designer  and  are  commonly  referred  to  as 
the  HOWS  of  the  HOQ.  The  HOWS  are  the  functions  for  the  OARS  system. 
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Functions  (Hows) 


Customer  Needs  (Whats) 

Mission  Start 

Patrol 

Communicate 

Engage 

End  Mission 

Detect 

0.3723 

0.3723 

3 

9 

3 

3 

Track 

0.1489 

0.1489 

9 

9 

9 

Intercept  Pirates 

0.2482 

0.2482 

3 

3 

9 

Neutralize  Threats 

0.1241 

0.1241 

3 

9 

Within  Compliance  with  mantme  law 

0.1064 

0  1064 

3 

3 

3 

Check  Sum 

1.0000 

1.00 

Weighted  Performance 
Percent  Performance 


2.5 

5.8 

3.6 

2.6 

2.6 

16.9 

0.145 

0.341 

0.212 

0.151 

0.151 

1.000 

Figure  11.  The  “What"s”  versus  the  “How"s”  prtion  of  the  HOQ. 


The  Functions,  which  were  introduced  in  the  beginning  of  Chapter  III,  included 
Mission  Start,  Patrol,  Communicate,  Engage,  and  End  Mission.  The  original 
stakeholder's  weights  and  driving  weights  from  the  original  AHP  diagram  drove  OARS 
to  be  a  primarily  patrol  based  system.  This  was  one  of  the  leading  requirements  that 
caused  OARS  to  rely  heavily  on  Unmanned  Aerial  Support  (UAS)  systems  and  extended 
range  mission  profiles.  Both  Mission  Start  and  Patrol,  from  the  field  of  functions, 
received  high  marks  on  the  matrix  shown  in  Figure  1 1 .  This  matrix  starts  to  translate  the 
OARS  systenT's  functions  into  the  system  physical  architecture.  These  were  the  start  of 
the  design  characteristics  that  were  used  to  define  the  physical  structure  of  the  system. 
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The  following  HOQ  matrix,  Figure  12,  is  the  matrix  between  Functions  and  Design 
Characteristics. 


System  Components 


Functions 

UAS  System 

Host  Vesel 

Pursuit  Vessel 

In  Theater  Command  and 
Control 

Fleet  Ships 

Mission  Start 

0.1760 

0  1760 

3 

3 

Patrol 

0.3626 

0.3626 

9 

9 

3 

Communicate 

0.2146 

0.2146 

9 

3 

9 

9 

Engage 

0.1322 

0.1322 

3 

9 

9 

End  Mission 

0.1147 

0  1147 

3 

6 

Checksum  1.0000 

1.00 

Weighted  Performance 

Percent  Performance 

5.7 

5.2 

3.0 

1.2 

3.8 

189 

0.303 

0.274 

0.160 

0.063 

0.201 

1.000 

Check 


Figure  12.  The  Functions  versus  Design  Components  of  the  HOQ. 


The  Design  Components  were  developed  to  reflect  a  flexible  architecture  needed 
to  effectively  meet  the  system  functions.  By  meeting  the  systenT's  functions,  OARS 
attempted  to  address  the  stakeholder";*  needs  and  expectations.  After  completing  an 
initial  trade  study  on  a  top  level  element,  the  top  level  components  were  selected.  The 
top  level  systems  were  based  on  feedback  from  stakeholders  and  industry  representatives" 
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interviews  and  were  chosen  to  allow  flexibility  for  further  analysis.  The  design 
components  included  a  UAS  system,  a  host  vessel,  a  pursuit  vessel,  in  theater  command 
and  control,  and  fleet  ships.  The  UAS  system  consisted  of  all  elements  needed  to  support 
an  unmanned  aerial  system.  The  UAS  responsibility  was  to  fulfill  the  primary  functions 
of  Detect  and  Communicate,  and  fulfill  the  driving  objectives  of  Detect  and  Track  pirate 
activities.  The  second  most  important  element  of  the  OARS  system  was  the  host  vessel. 
The  host  vessel  would  act  as  the  launch  and  recovery  platform,  detaining  center,  mobile 
base  of  operations  for  the  UAS  system,  and  pursuit  vessel.  The  pursuit  vessel  was  a 
system  element  designed  to  perform  the  Engage  function  and  fulfill  the  objectives  of 
Intercept  and  Neutralize  pirate  activities.  The  last  two  elements  consisted  of  fleet  ships 
and  in-theater  command  and  control.  These  two  reflect  the  OARS  system"s  primary  role 
as  a  subset  of  a  system  of  systems  already  in  place.  OARS  was  designed  to  seamlessly 
integrate  with  the  multinational  fleet  in  the  area,  to  operate  under  possible  command  and 
control,  and  to  work  with  American  and  allied  shipping  and  fleet  assets  in  the  area. 

Once  the  physical  architecture  was  defined,  the  performances  of  the  physical 
elements  were  compared  to  the  desired  target  values  using  the  MOEs.  The  MOEs  were 
built  in  a  manner  so  that  they  trace  back  to  the  objectives  of  the  system.  This  ensures  a 
mapping  between  the  objective  requirements  and  the  measurable  quantities.  The  MOEs 
were  Detect,  Classify,  Track,  Intercept,  Neutralize  and  Communicate.  These  MOEs 
allowed  for  the  direct  measurement  and  comparison  of  the  system  and  allowed  for  the 
rapid  development  of  the  performance  parameters.  The  “Detect”  MOE  encompassed  all 
aspects  of  detection  and  surveillance.  The  “Classify”  MOE  included  all  attributes  from 
vessel  databases  to  personnel  decisions  that  were  used  to  assess  the  hostility  of  a  vessel. 
The  “Track”  MOE  covered  the  systenf's  capacity  to  monitor  a  vessel  once  it  was 
determined  to  be  suspect.  The  “Intercept”  MOE,  which  had  the  lowest  score  of  the 
MOE"s,  reflected  the  systenf's  ability  to  match  headings  and  velocities  of  the  target 
vessels.  The  “Neutralize”  MOE  measured  the  OARS  systenf's  capability  to  reduce  the 
known  threats  and  make  them  inoperable  or  unable  to  carry  out  their  intended  role. 
Lastly,  the  “Communicate”  MOE  measured  the  systems  capability  to  interface  with  both 
operational  forces  and  with  neutral  shipping  vessels.  From  these  stakeholder  weightings 
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and  priorities,  the  KPPs  could  be  selected  from  the  list  of  derived  performance 
parameters.  These  were  then  directly  linked  through  the  physical  architecture  through  to 
the  functions  of  the  OARS  system  and  were  used  to  aid  in  the  definition  of  the  functional 
allocation.  Table  4  shows  the  OARS  KPPs. 


Table  4.  OARS  System  Key  Performance  Parameters  (KPPs). 


KPPs 

Units  of 
Measure 

Threshold 

Objective 

Source 

Percent  of  Detections 

Probability 

75% 

100% 

Derived  from  Anti-Piracy  Study 

Area  Covered 

Square  nautical 
miles 

390,000 

1,100,000 

Derived  from  Anti-Piracy  Study 

Sea  State  Operable 

Beauford  scale 

2 

5 

Derived  from  Anti-Piracy  Study 

Targets  Engaged 

Number 

1 

10 

Derived  from  Anti-Piracy  Study 

Number  of  Tracks 

Number 

1 

10 

Derived  from  Anti-Piracy  Study 

Time  to  Intercept 

Minutes 

24 

16 

Derived  from  Anti-Piracy  Study 

Number  of 

Engagements 

Number 

1 

10 

Derived  from  Anti-Piracy  Study 

Number  of 

Neutralizations 

Number 

1 

10 

Derived  from  Anti-Piracy  Study 

Safe  Transit 

%  of  ships  to 
safely  transit 

98% 

100% 

Stakeholder  Requirement 

Number  of  Prisoners 

Brig  capacity 

4 

20 

Stakeholder  Requirement 

Range  of 

Communication 

Miles 

100 

500 

Derived  from  Anti-Piracy  Study 

The  KPPs  column  shows  a  listing  of  the  different  KPPs.  Following  these  are  the 
units  of  measure.  The  KPPs  are  bound  by  the  threshold  and  objective  values.  The 
threshold  value  was  defined  as  the  minimum  required  value  for  the  OARS  system  to  be 
operationally  effective.  The  objective  was  the  value  that  once  exceeded,  would  not 
provide  any  further  benefit  to  the  system.  The  source  column  lists  where  the  data  was 
originally  found.  A  detailed  study  of  each  attack  in  FY  10  through  the  first  quarter  of 
FY  1 1  revealed  what  values  the  OARS  system  needed  to  meet  to  respond  to  the  pirate 
threats  in  and  around  the  Gulf  of  Aden  (ICC  Pirate  Attack  Report  2010-2011).  With  the 
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threshold  and  objective  values  set,  the  following  KPPs  were  determined  to  reflect  the 
refinements  of  the  need  to  deter  piracy. 

•  The  Percent  of  Detection  attribute  is  the  probability  of  sifting  out  a  pirate 
threat  from  the  background  maritime  traffic  in  the  area.  It  reflected  the 
success  rate  of  finding  a  pirate  threat  in  a  given  area. 

•  The  Area  Covered  attribute  was  the  square  mileage  of  ocean  that  was 
needed  to  be  covered  to  stop  a  pirate  threat  from  operating  in  a  given 
theater. 

•  The  Sea  State  Operable  attribute  reflects  the  need  for  the  OARS  system  to 
operate  in  the  same  conditions  that  the  pirates  are  willing  to  tolerate. 

•  The  Targets  Engaged  attribute  reflect  the  number  of  skiffs  and  pirate 
vessels  that  could  be  independently  engaged  at  one  time  during  an 
operation. 

•  The  Time  to  Intercept  attribute  was  determined  from  the  typical  response 
time  for  current  assets  to  respond  to  a  vessel  under  threat. 

•  The  Number  of  Engagements  attribute  reflects  the  number  of  independent 
operations  the  OARS  system  could  conduct  simultaneously. 

•  The  Number  of  Neutralizations  attribute  reflects  the  number  of  targets 
engaged  and  neutralized,  whether  by  lethal  or  non-lethal  force. 

•  The  Safe  Transit  attribute  is  the  percentage  of  shipping  vessels  that  the 
OARS  system  could  guarantee  safe  passage  through  troubled  seaways 
without  incident. 

•  The  Number  of  Prisoners  attribute  reflects  the  holding  capacity  of  the 
OARS  system  while  it  is  in  operation.  This  is  a  critical  aspect  that  is 
missing  from  the  current  CTF-151  system,  since  captured  prisoners  are 
forced  to  bunk  in  crew  quarters  until  processed. 

•  The  Range  of  Communication  attribute  determines  the  OARS  system"s 
capability  to  communicate  with  its  own  deployed  UAS  systems  and  all 
neutral  or  friendly  forces  in  the  area. 


With  these  quantities  known,  the  system  development  process  allowed  for 
iteration  and  inputs  into  the  modeling  and  simulation  field.  This  allowed  the  OARS  team 
to  quickly  and  efficiently  compare  competing  solutions  to  the  OARS  mission  profile. 
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D.  ARCHITECTURE 

After  the  OARS  system"s  MOEs  and  KPPs  were  developed,  the  team  then 
focused  its  attention  on  creating  the  architecture  of  the  system.  Developing  the  System 
Architecture  is  cornerstone  in  the  system"s  engineering  process  and  aids  in  the 
fundamental  development  of  the  system.  The  overall  System  Architecture  is  decomposed 
into  three  core  sections,  which  consist  of  Functional  Architecture,  Physical  Architecture, 
and  Allocated  Architecture.  The  Functional  Architecture  defines  what  the  system  must 
do.  The  Physical  Architecture  represents  the  partitioning  of  physical  resources  available 
to  perform  the  system"s  functions  (Buede  2009,  pg  27).  The  Allocated  Architecture  is  the 
mapping  of  the  functions  to  resources  or  physical  components.  Allocated  Architecture 
indicates  the  interfaces  and  data  flow  between  systems  or  functions.  This  will  be 
explained  in  Chapter  111,  Section  3,  Allocated  Architecture,  through  the  use  of  an 
Integrated  Definition  for  Function  Modeling  (IDEFO). 

Each  of  the  three  architectural  building  blocks  were  detailed  and  outlined  using 
CORE®  7,  from  Vitech  Corporation.  This  tool  provided  a  solution  for  managing  and 
tracking  requirements,  building  Functional-Physical  Architectures,  and  simulating 
functional  flow.  It  also  allowed  the  team  to  create  relationships  and  interfaces  between 
elements  to  outline  the  Allocated  Architecture,  while  allowing  for  configuration 
management  of  these  architectural  baselines.  A  summary  of  CORE®  7"s  element 
relationship  schema  is  shown  in  Figure  13.  The  elements  of  the  diagram  labeled  as  Item, 
Function,  and  Component,  were  the  only  elements  configured  into  the  baseline  of  the 
OARS  system.  However,  all  elements  contributed  to  describing  the  overall  System 
Architecture. 
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Figure  13.  CORE®  7  System  Engineering  Element  Diagram  (from  Vitech 

Tutorial  7.  Pg  3) 


1.  FUNCTIONAL  ARCHITECTURE 
a.  Functional  Analysis 

The  Functional  Analysis  was  developed  to  describe  the  functional 
requirements  of  the  system  and  outline  all  that  the  system  must  do  to  complete  its 
mission.  This  analysis  also  helped  to  identify  basic  internal  and  external  functional 
interfaces,  while  aiding  in  the  decomposition  of  upper-level  functions.  The  analysis  also 
aided  in  determining  fundamental  sequencing  of  these  upper-level  functions. 

After  analysis  of  current  anti -piracy  efforts  (CTF-151)  and  collaboration 
with  stakeholders,  initial  development  of  the  Functional  Hierarchy  was  completed. 
Figure  14  shows  the  top-level  hierarchy  of  the  key  OARS  functions  that  resulted  from  the 
Functional  Analysis.  These  functions  were  grouped  into  distinct  sequential  operations, 
labeled  as  Detect,  Fix/Classify,  Track,  Intercept,  Neutralize  Threat,  and  Communicate. 
In  general,  the  OARS  system  will  first  detect  a  vessel.  The  OARS  system  will  then  work 
to  identify  the  vessel  and  assess  the  risk  of  that  vessel  causing  harm  to  another  vessel. 
The  OARS  system  will  then  begin  to  track  that  vessel.  If  triggered,  OARS  will  then 
intercept  a  suspicious  vessel  and  neutralize  it.  Throughout  the  process  of  these  functions, 
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OARS  will  maintain  multiple  levels  of  communication  internally  and  externally  to  its 
environment.  A  formal  Functional  Hierarchy  was  modeled  in  CORE  where  each 
function  and  sub-function  is  detailed  in  the  subsequent  section. 


Figure  14.  Stakeholder  Functional  Analysis 


b.  Functional  Hierarchy 

Using  Figure  14,  the  Functional  Analysis  that  evolved  from  the 
stakeholder's  needs  analysis,  the  team  continued  on  in  developing  a  formal  Functional 
Hierarchy.  This  was  developed  using  a  combination  of  stakeholder  input,  team 
knowledge,  current  CTF-151  operational  analysis,  and  the  functional  requirements  of  the 
system.  The  Functional  Hierarchy  was  modified  multiple  times  as  the  overall  baseline 
was  developed  and  functional  deficiencies  were  revealed  in  the  system  architecture. 
Detect,  Fix/Classify,  Assess  Risk,  and  Track,  were  combined  in  a  functional  area 
renamed  as  Patrol.  Neutralize  and  Intercept  were  combined  into  the  functional  area  of 
Engage.  Mission  Start  and  Mission  End  are  functional  areas  that  were  added  to  indicate 
non-mission  critical  functions  that  are  required  for  complete  mission  fulfillment. 
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Figure  15,  Functional  Hierarchy,  is  the  formal  organized  tree  developed 
from  the  Stakeholder  Functional  Analysis.  Some  functions  were  renamed,  reclassified,  or 
divided  into  sub-functions,  which  evolved  throughout  the  architecture  process.  The  five 
major  functional  areas  (outlined  in  red)  are  decomposed  into  sub-functions  (outlined  in 
orange).  Specific  operational  details  of  each  sub-function  are  also  indicated  on  the  tree. 
Complete  descriptions  of  the  operational  details  are  outlined  in  Chapter  III,  Section  3, 
Allocated  Architecture. 
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Figure  15.  OARS  Functional  Hierarchy 
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2.  Functional  Flow  Block  Diagram  (FFBD) 

The  Functional  Flow  Block  Diagram  (FFBD)  is  another  way  of  organizing  the 
elements  of  the  Functional  Architecture.  After  detailing  most  of  the  functions  required 
by  OARS,  the  flow  and  sequence  of  each  was  described  since  the  Functional  Hierarchy 
does  not  capture  sequencing.  Since  the  architecting  process  was  iterative,  some  functions 
were  added  and  others  were  reorganized.  Outlining  the  functional  flow  helped  to 
recognize  gaps  and  deficiencies  in  the  functional  design.  The  FFBD  also  indicates 
recursive  functions  and  functions  that  are  conducted  simultaneously.  The  flow  of  each 
function  is  described  in  detail  from  the  Top  Level  (Level  1)  down  to  the  decomposed 
sub-function  levels  (Level  2  &  3). 

a.  Level  1  FFBD  -  OARS  Mission  Level 
As  outlined  previously  in  the  Functional  Hierarchy,  OARS  has  five  main 
mission  functions:  Mission  Start,  Patrol,  Engage  Hostile,  Communicate,  and  Mission 
End.  After  starting  its  mission,  the  OARS  system  begins  patrolling  an  area  and 
maintaining  vital  communication  with  external  and  internal  systems.  If  hostile  activity  is 
found,  the  OARS  system  will  be  invoked  to  engage  that  hostility.  This  process  repeats 
itself  until  mission  orders  are  given  to  end  the  mission.  The  mission  level  functionality  is 
then  completed.  Each  of  these  five  functions  will  be  explained  in  detail.  However,  the 
third- level  FFBD  breakdowns  are  included  in  Appendix  B. 

The  flow  of  each  function  is  shown  in  Figure  16.  It  must  be  noted  that  the 
annotations  at  the  bottom  of  each  box  are  actual  top-level  components  that  are  mapped  to 
the  corresponding  function.  This  is  part  of  the  Allocated  Architecture,  which  is  further 
explained  in  Chapter  III,  Section  3,  Allocated  Architecture. 
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Figure  16.  Top  Level  FFBD  for  the  OARS  System. 


b.  Level  2  FFBD  - 1  Mission  Start 

Figure  17  illustrates  that  the  first  step  of  Mission  Start  is  to  leave  home 
port.  It  will  transit  to  its  intended  destination  as  outlined  in  its  orders.  If  needed,  the 
OARS  system  conducts  an  Underway  Replenishment  (UNREP)  to  refill  fuel,  supplies, 
and  ammunition.  It  then  arrives  at  the  intended  operational  area  and  checks  in  with  the 
area  commander. 


Figure  17.  FFBD  1.0, , .Mission  Start." 
c.  Level  2  FFBD  -  2  Patrol 

After  completing  the  Mission  Start,  OARS  patrols  its  assigned  area  and 
conducts  surveillance.  This  can  be  seen  in  Figure  18  within  the  area  that  is  encompassed 
by  the  blue-dotted  line.  Patrolling  includes  everything  except  formal  engagement. 
OARS  must  first  detect  a  vessel  before  it  can  classify  it  and  conduct  a  risk  assessment.  If 
the  risk  assessment  is  high,  then  OARS  will  maintain  track  of  that  vessel  or  vessels.  It 
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continues  to  detect  and  classify  vessels  as  incoming  observations  continue.  The  Patrol 
function  cycles  throughout  the  mission  until  it  is  invoked  to  end  the  mission. 


Figure  18.  FFBD  2.0,  „Patrol." 


d.  Level  2  FFBD  -  3  Communicate 

Figure  19  shows  the  simultaneous  communication  functions  performed  by 
OARS.  Communicating  externally  includes  sharing  the  following  with  ally  units:  a 
Common  Operating  Picture  (COP),  Pirate  Attack  Risk  Surface  (PARS)  data,  and  other 
intelligence.  Communicating  externally  also  includes  notifying  the  fleet  of  hostile 
situations. 

Communicating  internally  includes  receiving  UAV  reconnaissance  data, 
intercepting  pirate  communication  channels,  and  exchanging  information  between  the 
individual  systems  that  comprise  the  overarching  OARS  system.  Note  how  the 
Communication  function  is  repeated  throughout  the  cycle.  It  is  conducted  throughout 
both  Patrol  and  Engagement  functions. 
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Figure  19.  FFBD  3.0, , Communicate." 


e.  Level  2  FFBD  -  4  Engage  Hostile  Activity 

While  conducting  a  patrol,  OARS  may  be  invoked  to  intercept  and 
neutralize  a  hostile  vessel  as  indicated  in  the  functional  flow  of  Figure  20.  This  function 
involves  assessing  the  risk  of  the  situation,  deploying  the  pursuit  vessel,  and  deterring 
and/or  boarding  the  hostile  vessel  to  ascertain  acts  of  piracy.  At  this  time,  arrests  may  be 
made  and  evidence  may  be  collected.  This  function  is  also  referred  to  as  a  VBSS  (Visit, 
Board,  Search,  and  Seizure).  If  the  hostile  vessel  is  seen  as  having  a  high  level  of  risk,  it 
is  immobilized  or  destroyed  to  nullify  an  escalating  situation.  Prisoners  and  evidence  are 
handed  over  to  local  authorities.  It  was  emphasized  by  stakeholders  that  the  OARS 
system  must  obtain  video  evidence,  as  this  is  the  strongest  anti-piracy  weapon  in  theater. 
After  completion  of  engagement,  OARS  continues  its  mission  of  Patrol  and  Engagement. 
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Figure  20.  FFBD  4.0,  „Engage  Hostile  Activity." 
f  Level  2  FFBD  -  5  Mission  End 

When  invoked  by  Mission  Orders  to  end  the  mission,  OARS  discontinues 
its  Patrol  and  Engagement  functions.  OARS  first  retrieves  its  UAVs,  checks  out  with  its 
commander,  and  then  returns  to  its  homeport.  This  is  shown  in  Figure  21. 


2.  PHYSICAL  ARCHITECTURE 

The  generic  Physical  Architecture  detailed  the  components  and  resources 
assigned  to  build  a  physically  operating  system.  Stakeholder  feedback  and  the  OARS 
teanf's  informal  feasibility  analysis  were  both  incorporated  into  the  design  of  the  Physical 
Architecture.  The  Physical  Architecture  was  developed  in  parallel  with  the  Functional 
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Architecture.  As  the  system  functions  were  elaborated,  the  physical  systems  needed  to 
satisfy  these  functions  were  specified.  Technology  Readiness  Levels  (TRL)  were  also 
considered  in  the  generation  process.  The  Physical  Architecture  has  many  uses, 
including  aiding  in  the  design  of  the  Work  Breakdown  Structure  (WBS)  and  aiding  in  the 
generation  of  alternatives  which  is  further  explained  in  Chapter  III,  Section  E,  Alternative 
Generation. 

The  majority  of  the  components  and  systems  used  by  OARS  have  already  been 
successfully  fielded  in  today"s  Navy.  These  components  include  Littoral  Combat  Ships 
(LCS),  RHIBs,  and  navigation  systems.  Some  components  may  either  currently  already 
be  developing  systems  with  high  TRLs  or  would  require  further  development  in  order  to 
obtain  higher  TRLs.  Developmental  systems  like  these  would  include  UAV  launch  & 
recovery  systems  for  multiple  UAYs,  or  additional  storage  systems  for 
contraband/evidence  or  detainees.  The  system  is  designed  to  easily  incorporate  the  use  of 
additional  reconnaissance  systems  such  as  Broad  Area  Maritime  Surveillance  System 
(BAMS)  or  augmented  reconnaissance  airships,  which  are  not  listed  as  a  part  of  this 
architecture. 

Referring  to  Figure  22,  the  system  is  broken  into  two  sections:  Internal  OARS 
Systems  (A.l)  and  External  Support  Systems  (A.2).  The  External  Support  System  is  a 
grouping  of  physical  systems  external  to  the  OARS  system  that  help  to  satisfy  some  of 
the  functions  needed  for  a  successful  OARS  mission.  As  stated  in  the  background  of  the 
problem,  the  Anti-Piracy  effort  in  the  Gulf  of  Aden  includes  foreign  navies,  thus  OARS 
must  include  them  as  a  part  of  its  operation.  These  external  support  systems  are  primarily 
involved  during  engagement  with  hostile  vessels. 

Internal  Systems  are  decomposed  into  the  Host  Vessel,  Pursuit  Vessel,  and 

Unmanned  Aircraft  Systems  (UAS).  The  lighter-blue  boxes  are  the  sub-systems  of  each 

individual  system,  which  may  be  further  decomposed  into  components.  The  UAS 

System  includes  the  UAV  and  its  launch  &  recovery  system.  The  Pursuit  Vessel  consists 

of  a  RHIB  boat  or  SH-60  Sea  Hawk  Helicopter,  depending  on  the  situation,  capabilities 

of  the  Host  Vessel,  and  the  mission  requirements.  The  Host  Vessel  contains  the  majority 

of  the  OARS  components.  In  addition  to  the  standard  operating  equipment  contained  on 
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a  LCS  or  DDG  ship,  the  Host  Vessel  also  contains  multiple  UAS  control  stations  and 
additional  storage  areas  for  evidence,  contraband,  and  detainees  until  they  are 
relinquished  to  authorities. 

The  next  section,  Allocated  Architecture,  is  where  the  Functional  and  Physical 
Architectures  come  together.  The  functions  in  Figure  15  are  satisfied  by  the  sub-systems 
in  Figure  22.  The  interactions  and  details  of  each  sub-system  are  fully  discussed  in  that 
section. 
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Figure  22.  OARS  Physical  Hierarchy, 
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3.  ALLOCATED  ARCHITECTURE 

Development  of  the  Allocated  Architecture  is  a  system  engineering  activity  in 
which  the  entire  process  comes  together  (Buede  2009,  pg  84).  It  integrates  the 
requirements  with  the  Functional  and  Physical  Architectures.  According  to  Buede,  the 
Allocated  Architecture  is  associated  with  five  major  development  activities  which 
include: 

•  Trace  system- wide  requirements  to  system  and  derive  component- wide 
requirements. 

•  Define  and  analyze  functional  activation  and  control  structure. 

•  Conduct  performance  and  risk  analysis. 

•  Document  architectures  and  obtain  approval. 

•  Document  subsystem  specifications. 

Reflecting  on  the  OARS  methodology,  some  of  these  developmental  activities 
were  done  independently  of  the  Allocated  Architecture  process.  Performance  and  Risk 
Analysis  were  conducted  early  in  the  design  process  during  the  generation  of  the 
CONOPS.  Information  from  this  analysis  was  then  directly  incorporated  into  the 
generation  of  the  Physical  Architecture. 

System  and  component-wide  requirements  were  developed  in  Chapter  III,  Section 
A,  System  Requirements.  Stated  as  a  functional  requirement  in  Section  A,  “The  OARS 
System  must  Detect,  Track,  Engage,  Neutralize  Targets,  Provide  Safe  Transit,  and 
Comply  with  international  maritime  law.”  A  physical  requirement  mandates  the  use  of 
UAVs  that  are  capable  of  conducting  surveillance  by  capturing  live-video.  These 
requirements  are  traced  to  corresponding  functions,  indicating  their  satisfaction  by  the 
way  of  functions  and  physical  components.  This  is  a  part  of  the  Allocated  Architecture, 
but  is  not  explicitly  detailed  in  this  section. 

As  mentioned  earlier,  the  Functional  and  Physical  Architectures  were  managed 
using  the  software  program,  CORE®  7.  These  architecture  baselines  were  installed  into 
the  program  to  allow  proper  organization  and  traceability  documentation.  The  Functional 
and  Physical  Architectures  were  mapped  together  to  produce  the  Allocated  Architecture. 
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Stakeholders  were  presented  fundamental  descriptions  of  the  architectures  and  concurred 
with  its  design. 

The  team  created  IDEFO  diagrams  using  CORE®  7.  IDEFO  diagrams  indicate 
interfaces,  data  flow,  information,  physical  items,  system  control,  and  functional  control, 
all  while  highlighting  the  physical  systems  that  satisfy  each  functional  activity.  IDEFO 
depictions  highlighted  any  misallocations  and  deficiencies  in  the  operation.  They  may 
also  be  reviewed  for  necessary  input  and  output  operations.  The  involved  functions  were 
organized  into  a  step-like  fashion  down  and  to  the  right  with  ample  control  triggers, 
feedback  loops,  and  input/output  arrows.  Functions,  which  are  labeled  in  red,  are 
referred  to  as  “Elements.”  Physical  systems,  which  are  labeled  in  blue,  are  referred  to  as 
„Components."  Plysical  items,  data,  and  information  are  referred  to  as  Jtems."  Items  are 
the  black  arrows  which  represent  the  flow  of  data,  information,  or  physical  items.  They 
may  be  either  inputs  or  outputs  to  a  function,  and  they  may  also  be  responsible  for  the 
control  of  each  function  or  sub-function.  In  the  following  section,  each  top-level  function 
of  the  Functional  Hierarchy  is  outlined  in  detail,  including  its  sub-functions. 

a.  Level  1  IDEFO  -  OARS  Mission  Level 

Figure  23  shows  that  a  typical  OARS  mission  starts  with  the  Mission  Start 
function,  which  is  first  invoked  by  Mission  Orders.  Although  Mission  Orders  is  a  trigger 
and  manipulates  the  functionality  of  certain  functions,  it  also  contains  data  which  is  fed 
as  inputs  to  the  Mission  Start  and  Patrol  functions.  Once  Mission  Start  is  enabled,  OARS 
will  depart  port,  complete  an  UNREP,  and  transit  to  its  operating  area  before  checking 
into  Fleet  Command.  This  function  is  satisfied  by  the  Host  Vessel. 
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After  check-in,  a  Patrol  Request  is  made  to  start  surveillance  routines. 
This  includes  detecting  vessels,  classifying  them,  assessing  their  risk,  and  tracking  them. 
In  particular,  surveillance  is  directed  towards  Suspicious  Vessels  that  have  either  been 
identified  by  civilian  vessels,  or  that  have  been  identified  by  the  OARS  UAVs  as  having 
pirate  paraphernalia  (i.e.  ladders,  drums  of  fuel,  etc.).  Physical  Systems  involved  with 
Patrol  are  the  Host  Vessel,  UAS  Host  Platform,  UAV  System  and  the  Host  Vessef's 
Transportation/Propulsion  System.  Patrolling  areas  are  determined  based  on  Mission 
Orders  and  external  Fleet  Surveillance  Data. 

Fleet  Surveillance  Data  that  is  fed  into  Patrol,  originates  from  external 
communication  with  the  fleet  and  other  vessels.  The  Communicate  function 
encompasses  all  internal  and  external  communication  for  the  OARS  system.  Externally, 
OARS  communicates  with  the  Fleet,  Commercial/Private  Vessels,  and  other  Nation 
States  or  allies  that  are  collaboratively  operating  in  the  area.  Internally,  Communicate 
includes  communication  with  both  the  OARS"s  UAVs  and  Pursuit  Vessels,  as  well  as  the 
sharing  of  surveillance  data.  Additionally,  it  receives  information  from  the  Patrol  and 
Engage  functions.  It  communicates  its  Engagement  Status  with  suspicious  vessels  and 
receives  Contact  Risk  Assessment  data  from  its  Patrolling  function.  Physical  Systems 
involved  with  Communicating  are  the  Host  Vessel,  Pursuit  Vessel,  UAV  System, 
Command  &  Control,  and  External  Support  Systems  such  as  CTF-151  or  allies. 
Communicate  functions  are  controlled  by  the  Mission  Orders,  which  dictates  how  it 
communicates  and  with  whom. 

OARS  may  receive  information  about  hostile  situations  from  its  patrol  or 

communication  with  the  fleet  and  civilian  vessels.  If  the  hostile  situation  involves  the 

hijacking  of  a  civilian  vessel,  then  OARS  sends  outs  a  Request  Special  Operations 

command  for  an  external  Special  Forces  team  to  intervene.  If  OARS  is  instructed  to 

intervene  upon  a  particular  hostile  situation,  an  Engage  Hostile  Request  is  initiated.  This 

triggers  the  function,  Engage  Hostile  Activity.  Contact  Identification  Data  and  Risk 

Assessment  Data  are  fed  into  this  function  from  Patrol.  Civilian  Vessels  and  Suspicious 

Vessels  interact  with  this  engagement.  OARS  will  first  attempt  to  intercept  the  vessel 

and  stabilize  the  situation.  If  not,  then  it  proceeds  to  neutralize  the  hostile  vessel.  A 

58 


VBSS  is  conducted,  which  may  result  in  arrests  of  Pirates  and  collection  of  Pirate 
Evidence  related  to  the  incident.  Pirates  and  associated  evidence  are  transferred  to 
appropriate  authorities  for  prosecution.  The  Host  Vessel,  Pursuit  Vessel  and  UAS 
System  are  the  physical  OARS  systems  involved  in  this  function.  The  Engagement 
Status  is  continually  communicated  internally  and  to  other  external  fleet  vessels.  As 
discussed  earlier  regarding  functional  flow,  OARS  will  return  to  Patrolling  or  end  its 
mission  after  completion  of  Engaging  Hostile  Activity. 

When  a  typical  OARS  mission  ends,  the  determination  is  controlled  by  the 
Mission  Orders.  Mission  End  includes  retrieving  IJAVS,  checking-out  with  the  fleet 
command,  completing  an  Underway  Replenishment  (UNREP),  and  transiting  back  to  the 
homeport.  These  functions  are  satisfied  by  the  Host  Vessel  and  Pursuit  Vessel,  which 
conclude  a  complete  OARS  Mission. 

b.  Level  2 IDEFO  - 1  Mission  Start 

The  start  of  a  typical  OARS  mission  does  not  vary  extensively  from  a 
typical  USN  DDG  or  LCS"s  mission  start,  as  the  initial  platform  for  OARS  is  derived 
from  these  vessels.  To  begin  a  mission,  Mission  Start  functions  are  first  initiated  by  a 
request  to  leave  port,  generated  by  Mission  Orders.  After  the  vessel  leaves  port,  UNREP 
functions  are  initiated.  Crew  members  are  assigned  to  their  tasks,  and  UAS  supplies, 
fuel,  and  ammunition  are  loaded  to  the  OARS  system  or  depleted  supplies  are 
replenished.  After  UNREP  is  reported  complete,  the  OARS  system  will  continue  onto  its 
operational  area.  After  arriving  at  its  operational  area,  the  Host  Vessel  checks-in  with 
Fleet  Command,  receives  its  current  orders,  and  then  initiates  its  patrol.  Figure  24 
outlines  the  physical  systems  involved  and  the  control  of  each  function. 
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Figure  24.  IDEFO  1.0,  fission  Start." 


c.  Level  2  IDEFO  -  2  Patrol 

The  Patrol  function  is  the  largest  set  of  operations  conducted  by  OARS. 
In  involves  Detecting,  Classifying,  Assessing  Risk,  and  Tracking.  Each  of  these  sub¬ 
functions  involves  detailed  operations  and  interfaces  with  other  OARS  functions. 

As  mentioned  previously  in  the  Mission  Level  diagram  of  Figure  23,  the 
Patrol  function  receives  Mission  Orders  and  external  Fleet  Surveillance  Data  while 
interacting  with  pirates.  The  Patrol  function  is  performed  by  the  Host  Vessel  and  UAS 
System.  To  other  functions,  the  Patrol  function  must  output  Contact  Identification  Data 
which  is  coupled  with  a  Contact  Risk  Assessment  of  anything  it  identifies  within  its 
Patrol. 


60 


The  Patrol  function  first  starts  with  Detect.  Request  Surveillance  starts  the 
process  while  Fleet  Surveillance  is  fed  into  it  to  help  determine  surveillance  plans.  A 
pattern  of  UAYs  are  launched  into  the  assigned  operational  area,  and  surveillance  is 
conducted  through  radar,  IR/FLIR,  and  the  interpretation  of  video  or  visual  data.  The 
UAV  Sensors,  Ship-Based  Control  unit,  and  ship"s  Combat  Sensor  System  participate  in 
this  function.  Raw  OARS  surveillance  data  is  fed  into  the  Tracking  and  Fix/Classify 
functions.  Contact  Identification  Data  is  a  specific  vessel  profile  which  contains 
identification  data,  risk  assessment,  surveillance  data,  tracking  data,  and  vessel  history. 

Fix/Classify  strictly  involves  identifying  vessels  and  tagging  them  each 
with  a  unique  identifier  for  tracking  purposes.  Differentiating  suspected  pirates  from 
local  civilians  has  posed  the  largest  problem  for  the  anti-piracy  efforts.  Classifying  each 
vessel  properly  is  a  critical  requirement  of  this  function:  hence  there  are  many  systems 
involved  in  determining  classification.  Information  retrieved  from  the  UAV  is  combined 
with  information  from  the  ship  and  fleet  to  identify  vessels.  These  inputs  are  surveillance 
data  and  tracking  information.  Once  a  contact  is  classified,  the  Risk  Assessment  function 
is  triggered  to  determine  the  risk  of  a  specific  contact. 

The  Assess  Risk  function  receives  external  Fleet  Surveillance  Data, 
Contact  Identification  Data  from  the  Fix/Classify  function  and  also  Tracking  Data  from 
the  Track  function.  Similar  to  the  Fix/Classify  function,  many  of  the  same  systems  are 
involved  in  assessing  a  contact' 's  risk.  A  contact  is  determined  to  be  hostile  or  non- 
hostile  based  on  information  received  from  classification,  the  vesseFs  known  track,  and 
retained  history  of  the  vessel.  After  analysis,  the  Contact  Risk  Assessment  is  mutually 
shared  with  other  OARS  systems  and  to  the  Fleet. 

The  Track  function  also  receives  the  Contact  Risk  Assessment 

information.  After  being  invoked  by  a  detection  from  the  Detect  function,  it  builds  a 

database  based  on  the  Contact  Risk  Assessment.  Paired  with  Contact  Identification  Data, 

OARS  will  use  this  information  throughout  its  overarching  Patrol  function  to  aid  in 

classification  and  risk  assessments  of  all  contacts.  Tracking  of  suspicious  vessels  and  all 

contacts  will  be  fulfilled  through  use  of  the  UAVs,  ship  combat  systems,  and  the  contact 

database  stored  within.  Additionally,  information  in  the  database  is  intermittently 
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communicated  to  the  fleet  through  use  of  the  OARS  Communicate  function.  The  1DEF0 
representation  of  these  interfaces,  data,  and  functions,  are  shown  in  Figure  25. 
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Figure  25.  IDEFO  2.0,  patrol.” 
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d.  Level  2 IDEFO  -  3  Communicate 

To  ensure  fluid  and  efficient  operations,  OARS  must  be  capable  of 
communicating  externally  to  fleet  operations  and  internally  to  its  other  systems.  As 
mentioned  previously,  the  Patrol  function  shares  Contact  Risk  Assessment  information 
and  Contact  Identification  data  with  the  Communicate  function.  While  this  function  is 
invoked  from  the  start  of  the  mission,  how  it  communicates  and  with  whom  it 
communicates  are  determined  by  the  Mission  Orders. 

OARS  communicates  externally  with  the  Fleet,  Nation  States,  and  Civilian 
Vessels.  It  receives  Fleet  Surveillance  Data  from  the  Fleet  and  shares  Contact  Risk 
Assessment  and  Identification  Data  with  them  as  contributions  to  the  Common  Operating 
Picture  (COP).  If  it  is  in  engagement  with  another  vessel,  it  will  share  that  status 
information  as  well.  In  general,  OARS  will  share  information  such  as  CASREP  reports, 
PARS  prediction  data,  intelligence  information,  COP,  and  also  request  the  assistance  of 
an  external  Special  Operations  team  if  a  civilian  vessel  has  been  hijacked.  OARS  does 
not  directly  engage  with  vessels  that  have  already  been  hijacked  since  its  primary  mission 
is  surveillance  and  deterrence.  The  OARS  host  vessel  can  host  Special  Operations  forces 
if  necessary. 

Internally,  OARS  Command  &  Control  communicates  with  its  UAVS, 
Pursuit  Vessel,  and  its  helicopter-based  Pursuit  Craft.  It  receives  surveillance  data 
through  data  links,  which  are  communicated  between  various  Patrol  and  Intercept 
functions.  It  also  intercepts  UHF,  LHF  and  satellite  information  that  typical  pirates  use  in 
their  piracy  missions.  Some  of  the  capabilities  involved  with  the  internal  communication 
function  are  sharing  radar  data,  communicating  with  the  UAVs,  exchanging  LHF/UHF, 
intercepting  pirate  communications  and  receiving  distress  calls. 

The  Ship  Communication  Suite  is  the  center  of  all  communications, 
whether  internal  or  external.  It  serves  as  a  link  between  communicating  externally  and 
communicating  internally.  Almost  every  system  in  OARS  has  some  level  of 
communication,  which  may  not  be  directly  linked  to  the  Ship  Communication  Suite.  For 
example,  the  On-board  UAS  Control  Station  communicates  directly  with  all  UAVs. 

Information  received  from  the  UAVs  is  then  shared  with  the  Ship  Communication  suite 
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by  way  of  the  onboard  UAS.  Figure  26  indicates  all  the  physical  systems  which 
participate  in  each  communication  domain. 
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Figure  26.  IDEFO  3.0,  Communicate." 

e.  Level  2  IDEFO  -  4  Engage  Hostile  Activity 

On  a  typical  mission,  OARS  continually  patrols  while  communicating 
information  it  receives.  If  it  interprets  a  situation  to  be  hostile  or  encounters  a  suspected 
pirate,  it  will  attempt  to  engage  that  hostile.  Engage  Hostile  Activity  is  invoked  by  a 
request  from  the  Communicate  function  which  originally  stems  from  Fleet  Surveillance 
Data,  Communication  with  Civilian  Vessels,  or  Contact  Risk  Assessment  Data  obtained 
through  surveillance.  Engaging  Hostile  Activity  is  served  primarily  by  the  Pursuit 
Vessel,  but  supplemented  with  the  UAV  and  Host  Vessel. 

The  request  to  engage  a  hostile  is  first  received  by  the  Intercept  function. 
This  complex  function  receives  any  information  from  the  Contact  Risk  Assessment, 
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Civilian  Vessels,  and  the  Suspicious  Vessels  themselves.  When  the  request  for 
engagement  is  made,  the  Intercept  function  first  selects  the  method  of  interception.  This 
is  decided  between  the  OARS  Command  &  Control  and  the  Fleet  Command  and  Control. 
Requests  are  then  made  to  dispatch  the  Pursuit  Vessel,  a  helicopter  or  a  RHIB,  along  with 
a  selected  Boarding  Team.  If  the  UAV  is  equipped  with  a  non-lethal  deterrence  system, 
such  as  a  smoke  screen  or  noise  maker,  it  may  participate  in  the  deterrence  function. 
After  dispatching  is  complete,  the  Pursuit  Vessel  crew  may  or  may  not  board  the  contact 
vessel.  If  so,  a  VBSS  continues  which  may  result  in  the  collection  of  evidence  and  the 
arresting  of  pirates.  Video  evidence  collected  by  the  Pursuit  Vessel  and  UAVs  is  also 
collected  as  evidence  and  is  transferred  to  the  Contraband/Evidence  Locker  and  the 
database  of  vessel  history.  After  deterrence  is  complete,  pirates  are  given  first  aid,  if 
required.  The  Pursuit  Vessel  also  continually  relays  its  engagement  status  internally  to 
the  OARS  Command  &  Control,  which  also  includes  the  risk  level  of  the  hostile  contact. 
When  the  risk  level  of  the  hostile  activity  reaches  a  certain  height,  the  Pursuit  Vessel  may 
relay  a  request  to  OARS  Command  &  Control  to  neutralize  the  hostile  activity.  This  is 
the  control  trigger  for  another  function,  Neutralize,  as  shown  in  Figure  27. 
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Request  -  Engage  Hostile 
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Intercept 
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Status  -  Engagement 


4.1  f 
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Pursuit  Vemsell 
Combat  System 
UAV  Sensor  Suite  * 

UAV  Flight  Computer 
UAV  Ship-Based  Control 
Ship  Communication  System 
Pursuit  Communication  System 

(UAV  Deterrence  System 


Request  - 
Neutralize  Hostile 
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4.2 

TTT~ 


-►  Pirates 


Pursuit  Vessel 
Boarding  Team 
Pursuit  Weapon  System] 


Figure  27.  IDEFO  4.0,  „Engage  Hostile  Activity.” 

Neutralize  is  invoked  by  the  Intercept  function,  when  the  hostile  activity 
reaches  an  intolerable  level  of  risk.  It  is  satisfied  by  the  Boarding  Team  and  Weapon 
System  operating  on  the  Pursuit  Vessel.  Weapon  support  from  the  Host  Vessel  is 
provided,  if  needed.  The  goal  of  the  Neutralize  function  is  to  disarm,  immobilize,  and 
capture  the  hostiles  in  a  joint  effort  to  minimize  the  potential  loss  of  life.  This  includes 
deterrence  of  a  potential  hijacking.  OARS  holds  this  function  as  the  last  resort  of 
elevated  pursuit,  before  notifying  special  operational  forces  of  OARS”s  failure  to  deter. 

The  request  to  neutralize  hostile  gives  the  Pursuit  Vessel  permission  to 
forcefully  escort  the  threat  away  from  the  civilian  vessel.  The  boarding  team  is 
consistently  fed  updated  information  about  the  pirate  vessel  and  other  local  threats 
throughout  the  Neutralize  process.  If  escorting  the  threat  fails,  the  team  attempts  to 
immobilize  the  hostile  personnel.  After  immobilization,  the  pursuit  team  is  invoked  to 
disarm,  capture  and  imprison  hostiles.  However,  if  the  Pursuit  team  fails  to  immobilize, 
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the  contacts"  risk  assessment  is  asserted  as  imminent  danger.  The  Boarding  Team  then 
proceeds  to  destroy  the  hostile  contact.  Remaining  prisoners  and  evidence  are  collected 
and  the  engagement  status  is  relayed  to  OARS  Command  &  Control.  The  prisoners  are 
given  first  aid  before  they  and  their  associated  contraband  are  handed  over  to  prosecuting 
authorities.  A  resulting  failure  of  the  Neutralize  function  indicates  that  the  civilian  vessel 
has  been  hijacked  and  hostile  activity  now  becomes  a  situation  for  the  special  operational 
forces,  a  scene  external  to  the  allocated  architecture  of  OARS. 

f.  Level  2 IDEFO  -  5  Mission  End 

The  conclusion  of  the  OARS  mission  is  dictated  by  the  Mission  Orders. 
Unless  the  OARS  system  becomes  substantially  operationally  deficient,  it  carries  out  its 
functions  throughout  the  duration  of  the  mission.  The  Mission  End  process  first  checks 
out  with  Command.  The  UAS  System  requests  retrieval  of  all  UAVs  currently  in  flight. 
The  Host  Vessel  refuels  through  completion  of  an  Underway  Replenishment  (UNREP). 
After  arriving  at  its  homeport,  OARS  exits  the  mission,  indicating  mission  completion. 
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Figure  28.  IDEFO  5.0,  ,JVHssion  End." 


E.  ALTERNATIVE  GENERATION 

The  alternatives  generation  phase  began  early  during  the  research  phase  of  our 
capstone  project.  Our  team  sought  to  answer  the  question:  “How  will  we  meet  the  needs 
of  the  customer?”  During  that  phase,  the  design  team  used  brainstorming  techniques  so 
as  to  not  limit  itself  to  an  early  solution.  This  section  will  review  some  of  the  proposed 
solutions  and  then  use  relevant  information  gathered  to  identify  which  of  our  alternatives 
were  not  viable  and  why.  The  alternatives  that  the  team  found  to  be  viable  are 
summarized  in  this  section. 

The  project  team  was  tasked  to  design  a  system  that  will  utilize  existing  surface 
warfare  assets  alongside  UAV  assets  to  counter  an  expanding  threat  to  surface  merchant 
trade  ships  and  private  vessels  by  pirate  gangs.  The  alternatives  generation  portion  of  the 
project  included  exploring  the  ability  to  utilize  the  current  government  off-the-shelf 

(GOTS)  systems.  GOTS  takes  existing  surveillance  and  detecting  systems  and  integrates 
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them  into  a  new  OARS  System.  The  team  evaluated  alternatives  from  a  variety  of 
articles  and  developers  on  the  need  for  a  pirate  interdiction  system  to  be  used  around  the 
globe  for  preventing  crimes  on  the  high  seas  toward  commercial  vessels.  Systems 
deployed  on  U.S.  Navy  ships  in  the  Gulf  of  Aden,  aircraft  used  during  visit,  board, 
search,  and  seizure  (VBSS)  activities  within  CTF-151,  and  airborne  UAVs  used  to 
monitor  activities  in  the  Middle  East  region,  all  provided  mature  technology  to  be 
uniquely  assembled  for  this  new  system  design. 

The  system  was  bounded  primarily  by  the  capabilities,  configuration,  and 
interfaces  of  the  host  ship.  The  most  well  suited  surface  ship  available  is  the  new  Littoral 
Combat  Ship  (LCS);  the  surface  warfare  module  was  well  matched  for  surface  search  and 
target  prosecution. 

1.  Materiel  Alternatives  Developed 

The  OARS  team  attempted  to  configure  different  alternative  solutions  from 
different  configurations  of  systems.  This  allowed  the  OARS  team  to  then  settle  upon  the 
best  alternatives  before  moving  onto  the  modeling  and  simulation  effort.  Our  physical 
alternatives  were  developed  based  on  our  top-level  systems  which  we  considered  variable 
and  highly  valuable  to  overall  system  effectiveness.  These  physical  systems,  chosen 
from  Figure  22,  were  the  UAS  System,  Host  Vessel  platform,  Pursuit  Vessel  platform, 
Weaponry,  Combat  Systems,  and  Surface  Sensors.  Remaining  physical  systems  did  not 
have  significant  variable  impacts  to  overall  OARS  effectiveness,  thus  were  not 
considered  when  the  team  determined  alternatives. 

a.  Alternative  #1.1 

The  first  design  alternative,  “Single  Platform  with  Stand  Alone 
Operations”  is  intended  to  perform  detection,  tracking,  and  prosecution  functions.  It  is 
called  the  “single  system  cell”  since  it  does  not  rely  on  any  other  systems  external  to  the 
OARS  to  perform  the  capability.  The  detection  capabilities  that  are  performed  include 
nine  ScanEagle  UAVs,  and  the  prosecution  capability  is  supported  with  the  use  of  two 
USMI  pursuit  vessels  with  double  barreled  .50  caliber  machine  guns  mounted  forward  of 
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the  conning  structure.  Due  to  the  fact  that  a  modified  version  of  Spain"s  DORNA 
(Direction  de  tiro  Optronica  y  Radarica  NAval)  fire  control  system  has  been  integrated 
into  the  U.S.  Navy"s  first  two  LCSs,  the  DORNA  fire  control  system  was  implemented 
into  Alternative  #l.l"s  configuration.  The  complete  list  of  systems  included  with  this 
alternative  is  shown  in  Table  5. 


Table  5.  Single  Platform  (Stand  Alone  Operations)  List  of  Systems. 


Combat  Systems 

Hard  Kill 

The  weapons 

Surface  Sensors 

Net  Central  C4ISR 

Host  Ship;  MK  110-57 
mm  Gun  (1) 

EADS  TRS-3D  C-band 
radar  (air  /  surface 
surveillance  LCS-1 

Secure  Communication 

50  Cal  Machine  Guns 

Sea  Giraffe  AMB  3-D 

Crypto 

(4) 

Radar 

Common  Operational 

AGM-114;  Hellfire 

EO/IR  Camera 

Picture 

missile  (4) 

(Star  SAFIRE) 

Fire  Control; 

M60;  7.62  mm 

DORNA  EO/IR 

DORNA 

Machine  Gun 

Camera 

Sensor  Processing 

ScanEagle  UAV 

SH-60  Helicopter 

b.  Alternative  #1.2 

The  second  design  alternative  is  the  “Single  Platform  Stand  Alone  Version 
with  an  alternative  UAV  sensor  named  ExDrone.”  This  alternative  is  intended  to  use  the 
OARS  for  detection,  tracking  and  prosecution  functions;  however,  it  will  use  an 
alternative  UAV.  The  combat  systems  category  remains  the  same  as  with  the  first 
alternative.  In  the  surface  sensors  category,  our  team  has  attempted  to  match  the 
capability  of  the  on-board  UAV  SAR  radar  and  EO/IR  camera.  The  complete  list  of 
systems  included  with  this  alternative  is  shown  is  Table  6.  Even  though  this  alternative 
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utilizes  a  different  UAV,  the  total  number  of  persons  required  to  operate  it  remains  the 
same  (two  per  shift). 


Table  6.  Single  Platform  (Stand  Alone  Operations)  List  of  Systems. 


Combat  Systems 

Hard  Kill 

The  weapons 

Surface  Sensors 

Net  Central  C4ISR 

Host  Ship;  MK  110-57 
mm  Gun  (1) 

EADS  TRS-3D  C-band 
radar  (air  /  surface 
surveillance  LCS-1 

Secure  Communication 

50  Cal  Machine  Guns 

Sea  Giraffe  AMB  3-D 

Crypto 

(4) 

Radar 

Common  Operational 

AGM-114;  Hellfire 

EO/IR  Camera 

Picture 

missile  laser  guided  (4) 

(Star  SAFIRE) 

Fire  Control; 

M60;  7.62  mm 

DORNA  EO/IR 

DORNA 

Machine  Gun 

Camera 

Sensor  Processing 

ExDrone  UAV 

SH-60  Helicopter 

c.  Alternative  #1.3 

The  third  design  alternative  is  the  Single  Platform  with  a  change  to  the 
surface  and  airborne  pursuit  vessels.  The  surface  vessel  is  being  changed  to  a  Zodiac 
rigid  hulled  inflatable  boat,  and  the  airborne  pursuit  vessel  is  being  changed  to  a  MQ-RB 
Fire  Scout  unmanned  helicopter. 

The  Fire  Scout  has  started  to  make  a  name  for  itself  in  recent  Naval 
missions.  Just  recently,  during  the  2011  Lybian  Civil  War,  a  MQ-RB  Fire  Scout  was 
used  in  targeting  missions  under  NATO  command.  The  Fire  Scout  is  denoted  as  a 
Vertical  Takeoff  Unmanned  Aerial  Vehicle  (VTUAV). 

The  cost  of  operating  a  VTUAV  in  place  of  a  manned  SH-60  helicopter  is 
significantly  less.  The  U.S.  Navy  expects  to  acquire  delivery  of  three  new  Fire  Scouts 
this  year  and  twelve  more  aircraft  in  2012.  According  to  one  report,  Congress  has  been 
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asked  to  boost  the  funding  for  this  VTUAV  by  $46  Million  in  2012  to  raise  the  inventory 
to  a  total  of  56  aircraft  by  the  end  of  2012  (Ackerman  2011).  The  difference  in  this 
alternative  would  be  most  notably  the  use  of  a  weapons  platform  UAV.  The  manning 
requirements  of  this  solution  are  very  low,  at  three  officers  and  three  enlisted  technicians 
per  UAV  system  compared  with  19  total  staff  to  support  an  air  detachment  for  an  SH-60 
Sea  Hawk  (Raymer  2009,  31)  (Stracker  2007,  pg.  v).  The  complete  list  of  systems 
included  with  this  alternative  is  shown  is  Table  7.  Even  though  this  is  an  unmanned 
UAV  pursuit  aircraft,  it  was  determined  that  there  would  be  a  requirement  for  two  UAV 
operators  aboard  the  host  ship. 

Table  7.  Single  Platform  (Stand  Alone  Operations)  List  of  Systems. 


Combat  Systems 

Hard  Kill 

The  weapons 

Surface  Sensors 

Net  Central  C4ISR 

Host  Ship;  MK  110-57 
mm  Gun  (1) 

EADS  TRS-3D  C-band 
radar  (air  /  surface 
surveillance  LCS-1 

Secure  Communication 

50  Cal  Machine  Guns 

Sea  Giraffe  AMB  3-D 

Crypto 

(4) 

Radar 

Common  Operational 

AGM-1 14;  Hellfire 

EO/IR  Camera 

Picture 

missile  laser  guided  (4) 

(Star  SAFIRE) 

Fire  Control; 
DORNA 

Two  pods  of  four 
70mm  folding  wing 
Hydra  rockets 

DORNA  EO/IR 
Camera 

Advanced  Precision 

Sensor  Processing 

Kill  weapons  laser 

ExDrone  UAV 

guided 

Fire  Scout  VTUAV 

Viper  Strike  precision 
munitions 

d.  Alternative  #1.4 

The  fourth  design  alternative  is  hosted  by  the  Littoral  Combat  Ship  (LCS). 
With  this  alternative,  the  team  would  not  alter  the  OARS  significantly  outside  the  UAV 
sensor.  This  alternative  is  shown  in  Table  8. 
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Table  8.  Single  Platform  (Stand  Alone  Operations)  List  of  Systems. 


Combat  Systems 

Hard  Kill 

The  weapons 

Surface  Sensors 

Net  Central  C4ISR 

Host  Ship;  MK110-  57 
mm  Gun  (1) 

EADS  TRS-3D  C-band 
radar  (air  /  surface 
surveillance  LCS-1 

Secure  Communication 

50  Cal  Machine  Guns 

Sea  Giraffe  AMB  3-D 

Crypto 

(4) 

Radar 

Common  Operational 

AGM-114;  Hellfire 

EO/IR  Camera 

Picture 

missile  laser  guided  (4) 

(Star  SAFIRE) 

Fire  Control; 
DORNA 

Two  pods  of  four 
70mm  folding  wing 
Hydra  rockets 

DORNA  EO/IR 
Camera 

Advanced  Precision 

Sensor  Processing 

Kill  weapons  laser 

ExDrone  UAV 

guided 

Fire  Scout  VTUAV 

Viper  Strike  precision 
munitions 

e.  Alternative  #1.5 

The  fifth  design  alternative  found  additional  options  in  the  host  ship.  The 
exceptional  Command,  Control,  and  Communications  capability  with  the  LPD  would  be 
available  as  a  single  cell  vessel  in  company  with  additional  destroyers  and  frigates 
combined  specifically  in  a  set  of  six  to  cover  the  Gulf  of  Aden  transit  corridors.  The 
extensive  aircraft  facilities  onboard  the  LPD  offers  the  six  system  cells  ample  support  but 
which  also  require  maintenance  and  repair  facilities  afloat.  With  this  alternative,  the 
team  would  build  a  duplicate  system  around  the  host  ship  as  in  alternative  1.1.  This 
Alternative  is  shown  in  Table  9. 

Table  9.  Single  Platform  (Stand  Alone  Operations)  List  of  Systems. 


Combat  Systems 

Hard  Kill 

The  weapons 

Surface  Sensors 

Net  Central  C4ISR 

Host  Ship;  MK  46  Mod 
1-30  mm  Gun  (2) 

Thermal  imager 
director  Camera 
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Secure  Communication 
Crypto 

MK26  Mod  18  50  Cal 
Machine  Guns  (2) 

Northrop  Grumman 
Norden  Systems 
AN/SPS-73  surface 
search  radar  operating  at 
I-band  (2) 

Common  Operational 
Picture 

AGM-114;  Hellfire 
missile  laser  guided  (4) 

Lockheed  Martin 
AN/APQ-9B  surface 
surveillance  and  tracking 
radar  operating  at  I  band 

Sensor  Processing 

M60;  7.62  mm 
Machine  Gun 

ScanEagle  UAV 

SH-60  Helicopter 

MK  2  SSDS  will  be  an 
integration  of  all  the 
ship's  self-defense 
systems  and  will  include 
multi-function  radar, 
advanced  integrated 
electronic  warfare 
system  and  infrared 
search  and  track  system 
(IRST). 

f.  Alternative  #1.6 

The  sixth  design  alternative  is  the  LPD  host  ship  upgrade  with  the  Fire 
Scout  VTUAV.  With  this  alternative,  the  team  would  build  a  system  around  an 
alternative  RHIB  named  Zodiac.  The  advantages  to  the  Zodiac  RHIB  over  the  USMI  is 
in  a  larger  personnel  capacity  and  its  increased  speed,  which  is  slightly  more  at  48  knots 
(versus  46  knots).  Additionally,  the  cost  is  a  quarter  of  that  of  the  USMI  vessel.  This 
alternative  is  shown  in  Table  10. 


Table  10.  Single  Platform  (Stand  Alone  Operations)  List  of  Systems. 


Combat  Systems 

Hard  Kill 

The  weapons 

Surface  Sensors 

Net  Central  C4ISR 

Host  Ship;  MK  46  Mod 

1-  30  mm  Gun  (2) 

Thermal  imager 
director  Camera 

Secure  Communication 
Crypto 

MK26  Mod  18  50  Cal 
Machine  Guns  (2) 

Northrop  Grumman 
Norden  Systems 
AN/SPS-73  surface 
search  radar  operating  at 
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I-band  (2) 

Common  Operational 
Picture 

AGM-114;  Hellfire 
missile  laser  guided  (4) 

Lockheed  Martin 
AN/APQ-9B  surface 
surveillance  and  tracking 
radar  operating  at  I  band 

Sensor  Processing 

M60;  7.62  mm 
Machine  Gun 

ScanEagle  UAV 

Fire  Scout  VTUAV 

Two  pods  of  four 
70mm  folding  wing 
Hydra  rockets 

MK  2  SSDS  will  be  an 
integration  of  all  the 
ship's  self-defense 
systems  and  will  include 
multi-function  radar, 
advanced  integrated 
electronic  warfare 
system  and  infrared 
search  and  track  system 
(IRST). 

Advanced  Precision 
Kill  weapons  laser 
guided 

Viper  Strike  precision 
munitions 

g.  Alternative  #1. 7 

The  seventh  design  alternative  is  the  fifth  alternative  with  the  alternative 
UAV  sensor,  ExDrone.  With  this  alternative,  the  team  would  be  able  to  measure  the 
effectiveness  of  the  alternate  UAV  with  the  more  advanced  LPD  support  package, 
considering  that  the  deployment  of  large  numbers  of  UAVs  and  Fire  Scout  armed 
VTUAVs  has  not  occurred  to  date.  The  maintenance  requirements  necessary  to  sustain 
this  configuration  will  be  valuable  modeling  and  simulation  data.  This  alternative  is 
shown  in  Table  6. 


Table  11.  Single  Platform  (Stand  Alone  Operations)  List  of  Systems. 


Combat  Systems 

Hard  Kill 

The  weapons 

Surface  Sensors 

Net  Central  C4ISR 

Host  Ship;  MK  46  Mod 

Thermal  imager 

1-30  mm  Gun  (2) 

director  Camera 
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Secure  Communication 
Crypto 

MK26  Mod  18  50  Cal 
Machine  Guns  (2) 

Northrop  Grumman 
Norden  Systems 
AN/SPS-73  surface 
search  radar  operating  at 
I-band  (2) 

Common  Operational 
Picture 

AGM-114;  Hellfire 
missile  laser  guided  (4) 

Lockheed  Martin 
AN/APQ-9B  surface 
surveillance  and  tracking 
radar  operating  at  I  band 

Sensor  Processing 

M60;  7.62  mm 
Machine  Gun 

ExDrone  UAV 

SH-60  Helicopter 

MK  2  SSDS  will  be  an 
integration  of  all  the 
ship's  self-defense 
systems  and  will  include 
multi-function  radar, 
advanced  integrated 
electronic  warfare 
system  and  infrared 
search  and  track  system 
(IRST). 

2.  OARS"sZwicky"s  Morphology 

The  seven  alternatives  were  evaluated  using  a  combination  of  procurement  costs 
and  mission  requirements.  A  procurement  cost  analysis  was  conducted  to  determine  the 
host  vessel  with  the  least  cost  to  be  utilized  by  the  OARS  system.  Since  the  CONOPS 
described  the  use  of  six  individual  OARS  systems  working  together  to  provide  coverage 
throughout  the  entire  Gulf  of  Aden,  a  total  of  six  different  host  vessels  was  required. 
This  cost  analysis  can  be  found  in  Appendix  E.  A  combination  of  six  Littoral  Combat 
Ships  (LCS)  was  the  cheapest  of  the  host  ship  combinations.  The  LPD  and  DDG 
platforms  are  considerably  more  costly  to  build  than  the  newer  LCS  ships,  at  over  a 
billion  dollars  each.  Another  issue  arises  with  the  fact  that  LFG  class  ships  will  not  be 
procured  in  the  future.  The  OARS  team  also  noted  that  integrating  several  UAVs  with 
two  ground  control  stations  across  three  different  ship  classes  would  be  difficult.  Due  to 
these  issues,  alternatives  1.5,  1.6  and  1.7  were  eliminated  immediately. 
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The  OARS  team  then  evaluated  how  each  of  the  other  alternatives  measured  up  to 
the  mission  requirements.  This  process  was  facilitated  using  a  simple  Zwicky"s 
morphological  box,  which  is  located  below  in  Table  12.  Mission  requirements  were 
placed  into  five  categories: 

1 .  Combat  systems 

2.  Sensors 

3.  Capture  and  Detention 

4.  Weapons 

5.  UAV  Endurance 


Table  12.  Zwicky"s  Morphological  Box. 


Combat 

Systems 

Sensors 

Capture  and 
Detention 

Weapons 

UAV 

Endurance 

LCS 

IR 

Armed, 

Manned  Helo 

LCS 

<  5  hrs 

▲  • 

COP 


High  Altitude 
UAV 


EO 


Video 


Armed, 
Manned^+~* 
Pursuit  Boats 


Helo 


5-15  hrs 


Brig  Facility  Pursuit  Boats  >  15  hrs 


★ 

=  Alternative  1.1 

A 

=  Alternative  1.2 

=  Alternative  1.3 

« 

=  Alternative  1.4 
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The  remaining  alternatives  adequately  supported  combat  systems,  sensors,  and 
weapons  requirements.  Alternatives  1.1  and  1.2  satisfy  the  “capture  and  detention” 
requirement  the  best  by  including  a  SH-60  helicopter.  Alternatives  1.3  and  1.4  utilize  the 
MQ-B8  Fire  Scout  VTUAV  instead  of  the  SH-60  helicopter.  The  VTUAV  is  a  very 
capable  system  and  has  a  lower  life  cycle  cost  than  the  SH-60,  however,  due  to  its  limited 
“capture  and  detention”  capabilities,  it  was  not  considered  as  a  preferred  option  for  the 
OARS  system.  The  SH-60  will  also  prove  more  valuable  in  keeping  detected  pirates  at 
bay  until  the  pursuit  vessels  arrive.  For  this  reason,  Alternatives  1.3  and  1.4  were  not 
considered  as  optimal  for  the  OARS  system. 

The  next  subsystem  evaluation  criteria  examined  by  the  OARS  team  was  the 
endurance  of  the  UAVs.  Although  the  ExDrone  UAV  option  was  found  to  be  less  costly, 
it  suffers  when  it  comes  to  endurance.  Its  mission  is  limited  to  less  than  5  hours,  while 
the  ScanEagle  has  an  endurance  of  over  18  hours.  Much  more  time  will  be  spent 
searching  for  pirates  over  a  much  greater  area  if  the  ScanEagle  UAV  is  used  instead  of 
the  ExDrone.  Both  Alternatives  1.1  and  1.3  utilize  the  ScanEagle  UAV  and  therefore 
they  both  perform  the  best  when  it  comes  to  UAV  endurance.  Due  to  the  fact  that 
Alternative  1 . 1  provides  both  a  strong  “capture  and  detention”  capability  and  provides  a 
very  large  UAV  endurance  range,  it  was  selected  as  the  most  preferred  alternative. 
Alternative  1.1  can  be  adjusted  to  add  up  to  12  ScanEagles  per  OARS  system.  The 
simulation  will  also  evaluate  an  augmented  configuration  incorporating  a  long  range 
airship  such  as  BAMS. 

3.  Recommended  Alternatives 

a.  Alternative  1,  Basic  OARS 

Due  to  the  results  of  the  Zwicky"s  Morphology  Box,  Alternative  1 . 1  will 
be  carried  into  the  analysis  phase  of  the  systems  engineering  process  and  will  be 
considered  as  “Basic  OARS.”  The  subsystems  that  will  make  up  Alternative  1  are 
detailed  in  Table  5. 
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b.  Alternative  2,  Augmented  OARS 

The  other  alternative  that  was  selected  to  be  modeled  had  the  same 


configuration  as  Alternative  1.1,  but  also  was  augmented  by  Wide  Area  Surveillance 
airships  or  BAMS.  This  allowed  the  OARS  team  to  analyze  the  benefits  of  adding  a 
land-launched  airship  to  the  Basic  OARS  system  to  allow  for  greater  surveillance  of 
pirate  activity.  The  analysis  of  both  alternatives  is  further  discussed  in  the  next  Chapter. 
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IV.  MODELING  AND  ANALYSIS 


A.  TOOLS  AND  APPROACH 

The  Naval  Simulation  System  (NSS)  software  package,  which  was  used  for 
modeling  and  simulation  (M&S)  of  the  OARS  system,  was  developed  by  the  Space  and 
Naval  Warfare  Center  SPAWAR  (PD- 15)  (Information  Support  Systems)  and  Metron 
Inc.  from  Reston,  VA.  This  software  uses  object-oriented  Monte  Carlo  Modeling  to 
simulate  complicated  interactions  between  individual  objects.  NSS  is  centered  around 
the  support  of  operational  commanders  in  developing  and  analyzing  operational  events 
that  are  driven  by  either  decisions  made,  or  the  selected  courses  of  action  at  a  mission 
group  or  force  level. 

The  OARS  Team  used  the  scenario  based  modeling  within  NSS  for  the  purpose  of 
establishing  base-line  functional  models,  applying  variances  to  the  models  to  test  each 
alternative  effectively,  and  capturing  the  necessary  data  from  alternatives  in  order  to 
compare  quantitative  output  values.  This  provided  the  team  with  a  set  of  feasible 
alternative  system  arrangements  that  were  tested  against  the  identical  constraints.  This 
helped  to  frame  the  best  solution  to  this  system. 

The  basis  of  selecting  NSS  was  primarily  because  of  its  capability  for  modeling 
two  opposing  forces  in  a  dynamic  environment  with  a  geographic  world  overlay  for 
reference.  Each  study  was  primarily  focused  on  reducing  the  number  of  successful  pirate 
attacks  based  on  known  effective  deterrents.  Specific  resources  can  then  be  allocated  to 
experimental  combinations  of  surface  ships,  helicopters,  and  UAVs,  with  the  overall  goal 
of  deterring  piracy.  Allocating  specific  resources  primarily  refers  to  having  compatible 
combinations  of  surface  combatants  loaded  with  accompanying  helicopter  crews  and  a 
UAV  detachment,  working  together  to  combat  the  threat  of  piracy.  The  allocation  of 
experimental  resources  refers  to  combining  relatively  untested  combinations  of  resources. 
Examples  of  these  untested  resources  were  a  blimp-like  airship  and  an  array  of  UAVs 
that  were  deployed  to  assist  in  combating  the  threat  of  piracy.  The  individual  scenarios 
setups  in  NSSs  will  be  laid  out  in  more  detail  in  the  “Model  Scenario”  section  of  this 
chapter. 
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The  basic  methodology  when  conducting  OARS  system  modeling  and  simulation 
(M&S)  was  to  provide  a  multi -preference  objective  model  that  allowed  the  Measures  of 
Effectiveness  (MOEs)  to  be  weighed  in  accordance  with  the  systems  engineering  process. 
The  MOEs  were  measures  drawn  from  the  original  stakeholder  requirements  and  mapped 
to  the  available  outputs  from  the  NSS  program  scenarios.  Table  13  below  lists  the  MOEs 
that  were  used  to  establish  the  modeling  criteria.  The  MOEs  were  taken  from  default 
MOE  templates  available  within  the  NSS  program. 


Table  13.  Measures  of  Effectiveness  (MOEs). 


Name 

Rank 

;  Template  (NSS) 

Red  Assets  Destroyed  (Pirates  Overtaken) 

1 

Asset  Destroyed 

Blue  Assets  Destroyed  (Cargo  Ships  Overtaken) 

2 

Asset  Destroyed 

Red  Weapon  Launches  (Pirate  Overtake 

Attempts) 

3 

Weapon 

Launched 

Blue  Weapon  Launches  (OARS  Overtake 
Attempts) 

4 

Weapon 

Launched 

Blue  Surveillance  Classifications  (OARS) 

5 

Surveillance 

Classifications 

UAV  Cumulative  Launches  (OARS) 

6 

Aircraft 

Cumulative 

Launches 

Blue  Surveillance  Detections  (OARS) 

7 

Surveillance 

Detections 

Throughout  the  following  explanations  of  the  modeling  setup,  red  and  blue  assets 
will  refer  to  the  two  opposing  forces  that  were  set  up  in  NSS  to  model  the  behavior  of  the 
OARS  system  and  its  components.  NSS  and  the  two  opposing  forces  are  discussed  in 
further  detail  below.  The  MOEs  were  an  integral  portion  of  the  model  design  and  were 
necessary  in  comparing  the  various  system  alternatives.  The  MOEs  were  gathered  as 
outputs  from  the  model.  Results  from  the  model  are  outlined  in  further  detail  in  the 
“Results”  section  of  this  chapter. 

Modeling  efforts  were  focused  on  accurately  simulating  pirate  and  cargo  ship 
activity  in  the  Gulf  of  Aden  to  cover  approximately  390,000  square  miles  of  effective 
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piracy  interdiction.  The  simulation  efforts  continually  grew  from  the  modeling  successes 
where  initial  run  data  was  able  to  pass  basic  validity  tests  of  plausible  and  non-plausible 
data.  The  initial  analysis  of  such  data  helped  to  produce  a  confidence  in  the  data  that  was 
being  produced  while  modeling  the  current  CTF-151  system  and  the  alternative  OARS 
scenarios.  These  efforts  were  accomplished  by  using  NSS"  study  management  and 
export  tools  to  output  multiple  replications  of  scenarios  to  Microsoft  Excel  for  analysis. 
The  more  robust  tools  within  the  NSS  proved  to  be  more  difficult  to  master  as  students, 
but  perseverance  and  assistance  from  the  OARS"s  capstone  advisor  allowed  the  group  to 
successfully  model  four  separate  alternative  scenarios. 

While  modeling  OARS,  two  opposing  forces  (red  and  blue)  were  created.  The 
blue  forces  consisted  of  U.S.  Navy  surface  ships,  UAVs,  and  merchant  vessels.  These 
blue  forces  were  pitted  against  the  red  forces,  which  consisted  of  red  pirate  surface  craft 
who  were  attempting  to  hijack  and  ransom  merchant  vessels.  Scenarios  were  developed 
by  introducing  specific  ship  paths,  tactics,  defensive  actions,  and  hostile  actions. 
Background  information,  such  as  the  origin  of  pirate  attacks  and  known  merchant 
shipping  lanes,  were  learned  during  the  OARS  teairTs  initial  piracy  research.  Figure  29 
below  shows  a  NSS  screenshot  displaying  the  cargo  tracks  used  as  a  baseline  to  simulate 
the  busiest  corridor  through  the  Gulf  of  Aden. 


Figure  29.  NSS  Cargo  Track  Display. 
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Table  14  outlines  the  matrix  used  to  develop  objects  in  modeling  scenarios. 
Scenario  development  consisted  of  setting  up  two  separate  alliances.  Each  of  the 
alliances  were  assigned  resources,  some  of  which  are  shown  below.  Commanders  were 
assigned  to  each  of  the  alliances  in  order  to  assign  alliance  tactics,  object  properties,  and 
movement  actions.  Individual  entity  tactics  and  properties  are  discussed  in  further  detail 
in  the  , Modeling  Tactics"  section  of  this  chapter. 

B.  MODEL  SCENARIOS 

Table  14  outlines  the  number  of  ships  used  for  each  of  the  four  modeling 
scenarios.  The  four  modeled  scenarios  are  described  in  more  detail  in  the  following 
sections.  All  scenarios  had  a  time  frame  of  a  30  day  window  to  simulate  the  number  of 
interactions  in  a  single  month.  The  30  day  window  was  also  chosen  to  decrease  NSS 
server  processing  time  when  running  multiple  replications  through  the  study  management 
mode. 


1.  Pirates  Unopposed  (Baseline) 

This  scenario  was  the  baseline  model  where  the  pirates  were  unopposed  and 
openly  attacked  merchant  vessels  without  resistance.  Container  ships  were  assigned 
repeating  tracks  travelling  through  the  corridor  of  the  Gulf  of  Aden  through  which  ships 
transit.  Originally,  500  cargo  ships  were  to  be  modeled  going  back  and  forth  through  the 
gulf,  but  due  to  NSS  memory  limitations,  the  OARS  team  was  forced  to  scale  this 
number  down  to  355.  The  container  ships  were  assigned  an  in-and-out  track  that  they 
would  travel,  which  was  straight  down  the  middle  of  the  Gulf  of  Aden.  One  hundred 
pirate  motherships  and  200  pirate  skiffs  (two  per  mothership),  were  equally  divided 
among  five  separate  but  equally  sized  regions  within  the  390,000  square  miles  in  the  Gulf 
of  Aden.  Within  each  region,  20  red  pirate  motherships  were  assigned  a  patrol  movement 
in  which  the  motherships  would  actively  search  for  blue  container  ships  to  attack. 
Motherships  were  given  a  “visual  radar”  property  to  allow  them  to  scan  for  container 
ships  up  to  nine  miles  away,  which  is  reasonable  given  the  size  of  the  ships  and  the 
assumption  that  binoculars  may  be  used.  Upon  confirmation  of  container  ship  sighting 
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within  a  nine  mile  radius,  the  mothership  would  launch  attack  pirate  skiffs.  When  the 
pirate  skiffs  arrived  at  the  container  ships,  the  attack  would  begin  and  a  successful 
overtake  of  the  container  ship  being  successfully  undertaken  would  be  reported  when  the 
blue  ship  was  eliminated.  This  baseline  allowed  additional  follow-on  scenarios  to  be 
built  upon  its  structure:  additionally,  it  provided  a  “worst  case  scenario”  number  of 
successful  pirate  attacks  without  any  opposition  from  U.S.  or  allied  naval  forces.  The 
MOE  data  was  gathered  after  running  the  scenario  for  three  replications  and  then  the  data 
was  exported  to  an  Excel  spreadsheet  for  analysis. 


Table  14.  Scenario  Objectives  and  Quantities. 


Object  Name 

Baseline  1 

-  No 

Naval 

Support 

Baseline  2-  CTF 

151  (Scaled  to  .39 

Million  sq.  miles) 

OARS 

Alternative  1 

-LCS  Host 

Ships 

OARS 

Alternative  2  - 

LCS  Host  Ships 

w/ Air  Support 

AK  Amur  Cargo  Ships 

355 

355 

355 

355 

Pirate  Motherships 

100 

100 

100 

100 

Pirate  Skiffs 

200 

200 

200 

200 

SH-60  Helos 

0 

2 

0 

0 

USN  LCS  Class  Ships 

0 

0 

6 

6 

USN  DDG  Ai  liegh  Burke  Class  Ships 

0 

2 

0 

0 

USN  FFG  Perry  Class  Ships 

0 

1 

0 

0 

USNLPD  San  Antonio  Class  Ships 

0 

1 

0 

0 

Chinese  Jianwei  Frigates 

0 

2 

0 

0 

Korean  USLAN  Frigates 

0 

1 

0 

0 

Turkey  Barbaros  Frigates 

0 

3 

0 

0 

Singapore  Formidable  Frigates 

0 

2 

0 

0 

Canadian  Halifax  Frigates 

0 

1 

0 

0 

French  Floreal  Frigates 

0 

1 

0 

0 

Dynalifter  Hybrid  Airships 

0 

0 

0 

1 

Scan  Eagle  UAVs 

0 

2 

54 

54 
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2.  CTF-151  (Currently  Existing  Scenario) 

This  scenario  was  modeled  to  simulate  the  current  efforts  of  the  CTF-151 
coalition  force.  CTF-151,  as  previously  explained,  consists  of  U.S.  Navy  and  allied  ships 
working  together  to  combat  piracy  in  the  Gulf  of  Aden.  The  blue  Navy  alliance  ships 
that  were  modeled  included  a  DDG  51  Arleigh-Burke  Class  destroyer,  LPD  17  San 
Antonio  Class  Amphibious  assault  ship,  and  a  FFG  Oliver  Hazard  Perry  Class  Frigate. 
Also  included  in  the  “Blue”  alliance  were  ten  coalition  vessels  which  make  up  the 
majority  of  CTF-151.  Coalition  vessels  included  Chinese  Frigates  (Jianwei  Class), 
Korean  Frigates  (ULSAN  Class),  Turkey  Frigate  (Barbaras  Class),  Singapore  Frigate 
(Formidable  Class),  Canadian  Frigate  (Halifax  Class),  and  French  Frigate  (Floreal  Class) 
platforms.  Though  the  Chinese  Frigates  are  not  strictly  part  of  CTF-151,  they  are 
deployed  there  to  protect  the  commercial  interests  of  the  Chinese  government  and  assist 
with  the  overall  effort  to  deter  piracy.  Certain  coalition  vessels  were  modeled  with  SH- 
60  SeaHawk  Helicopter  capabilities;  these  were  the  Singapore  ships  and  Turkish  ships. 
Coalition  vessels  that  were  modeled  with  UAVs  were  the  Canadian  Frigates  (SH3D  Sea 
King)  and  the  French  Frigate  (Z9C  Dauphin).  Refer  to  Table  14  above  for  the  exact 
number  of  each  of  the  coalition  and  Navy  ships  modeled  in  this  scenario.  All  ships  had 
inherent  weapon  properties  that  were  adjusted  in  order  to  reflect  international  law  that 
suspected  pirates  are  not  to  be  treated  as  enemy  combatants.  Thus  all  missile  launch 
capabilities  and  anti-aircraft  guns  were  removed,  allowing  only  small  caliber  deck 
machine  guns  to  be  utilized.  Each  ship  was  assigned  a  patrol  track  in  each  of  the  six 
equally  sized  pirate  zones  which  allowed  them  to  deter  and  intercept  pirates  only  in  their 
region.  All  sensor  properties  were  left  at  the  default  NSS  inherited  value.  This  allowed 
the  ships  to  detect  the  presence  of  motherships  and  thus,  the  pirate  skiffs.  The  100  pirate 
motherships  with  accompanying  200  pirate  skiffs  were  carried  over  from  the  baseline 
scenario  and  modeled  identically.  SH-60  Helicopters  and  a  limited  number  of  UAVs 
were  added  to  this  scenario  to  reflect  the  current  limited  use  of  UAVs  utilized  in  CTF- 
151  presently.  UAVs  were  treated  as  aircraft  objects  in  the  model  and  therefore  the 
inherent  properties  of  the  UAVs  were  left  at  default  inherited  NSS  values.  Pirate  kills 
were  recorded  as  pirate  ships  that  were  overtaken  and  confirmed  through  a  MOE  output 
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of  Red  Asset  Destroyed.  Data  was  gathered  for  three  scenario  replications  and 
automatically  exported  to  a  spreadsheet  for  analysis. 


3.  LCS  Host  Vessel  with  UAVs  (OARS  Basic) 

This  scenario  was  modeled  using  multiple  UAVs  to  increase  the  sensor  range  of 
the  surface  ship  as  well  as  increase  the  sensor  effectiveness  of  the  blue  alliance.  This 
scenario  introduced  six  Littoral  Combat  Ship  (LCS)  host  vessels  and  36  ScanEagle  UAVs 
(6  per  LCS)  for  piracy  detection  sensors.  For  an  exact  breakdown  of  the  number  of 
platforms  modeled,  please  refer  to  Table  14.  All  host  ship  platforms  used  in  NSS  had  the 
built  in  capability  to  launch  and  recover  multiple  UAVs.  In  this  scenario,  all  of  the  U.S. 
Navy  ships  and  coalition  vessels  were  again  divided  equally  among  the  six  piracy  zones. 
All  200  pirate  skiffs  and  100  motherships  left  at  their  previously  assigned  zones  with  the 
red  alliance.  All  blue  Navy  assets  were  assigned  the  same  patrol  sweeps  to  look  for 
pirates  as  in  the  CTF-151  scenario  described  above.  The  UAV  that  was  assigned  to 
launch  from  all  U.S.  Navy  ships  was  the  ScanEagle  with  a  patrol  track  within  one  of  the 
five  designated  piracy  areas.  Upon  confirmation  of  a  pirate  vessel  sighting,  the  UAV 
would  report  back  to  the  host  vessel  and  the  host  vessel  would  utilize  its  superior  speed 
and  range  to  attempt  to  overtake  and  eliminate  the  pirate  threat.  This  overtake  action  was 
not  explicitly  shown  in  the  model  due  to  the  fact  that  the  action  of  overtaking  a  pirate 
vessel  was  measured  through  the  Red  Asset  Destroyed  MOE.  Though  the  speed 
properties  assigned  to  pirate  skiffs  were  greater  than  all  of  the  U.S.  Navy  and  coalition 
ships,  the  craft' 's  range  was  limited.  For  an  exact  breakdown  of  derived,  assumed,  and 
calculated  values  for  pirate  skiffs  and  motherships,  please  refer  to  Appendix  C.  Once  the 
pirate  skiffs  returned  to  the  pirate  mothership,  the  speed  of  the  mothership  was  limited  to 
that  of  a  typical  fishing  vessel,  allowing  any  one  of  the  blue  alliance  to  overtake  and 
eliminate  the  threat.  Data  was  gathered  from  three  replications  of  the  scenario  and 
automatically  exported  to  a  spreadsheet  for  analysis. 

4.  LCS  with  Air  Support  Vessel  (OARS  Augmented) 

During  the  modeling  and  scenario  development  for  the  LCS  with  Air  Support 

concept,  the  NSS  program  database  was  erased  through  a  Naval  Postgraduate  School 
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(NPS)  technician"s  error.  This  ultimately  wiped  out  all  existing  OARS  scenarios.  This 
loss  of  data  erased  all  earlier  model  development  and  did  not  allow  the  team  to  complete 
the  scenario  listed  below.  Therefore,  this  scenario  is  described  purely  as  an  area  for 
further  research  and  future  investigation,  as  there  was  no  output  data  available. 

This  scenario  was  to  be  modeled  identically  to  the  LCS  host  ship  scenario 
(OARS  Basic),  with  the  added  support  of  a  hybrid  airship  to  increase  the  detection  range 
and  effectiveness  of  the  blue  alliance.  The  unmanned  airship  was  to  be  land-based  but 
capable  of  greater  endurance  and  range  to  exponentially  increase  the  sensor  effectiveness 
of  the  alliance.  As  seen  from  Table  14,  the  six  LCS  class  were  all  to  be  modeled  with 
associated  ScanEagle  UAVs.  The  airship  selected  for  this  scenario  was  the  MDL- 100X1 
Dynalifter.  This  aircraft  was  not  available  in  the  default  database  of  objects  in  NSS  so  an 
equivalent  aircraft  was  chosen  to  simulate  it  as  closely  as  possible.  The  baseline  aircraft 
for  modification  to  the  airship  was  an  E2  Hawkeye.  Speed,  range,  detection  capability, 
and  fuel  capacity  properties  were  all  altered  to  reflect  the  MDL- 100X1  Dynalifter  as 
closely  as  possible.  The  actual  detection  capability  of  the  MDL- 100X1  Dynalifter  is 
extensive,  but  still  not  quite  as  effective  as  the  actual  E2  Hawkeye  so  the  sensor 
capability  property  was  adjusted.  As  in  previous  scenarios  the  blue  alliance  ships  were 
divided  between  the  five  zones  along  with  their  accompanying  UAV  squadrons.  One 
“MDL- 100X1  Dynalifter”  was  assigned  to  this  scenario  and  its  path  was  a  racetrack  path 
around  the  entire  Gulf  of  Aden  operating  area.  This  scenario  was  fully  modeled,  but 
because  of  the  deletion  of  the  NSS  database,  no  outputs  could  be  measured. 

C.  MODELING  PARAMETERS 

Modeling  tactics  were  based  on  assignable  tactics  table  actions  available  within 
NSS.  The  tactics  essentially  dictated  how  the  model  object  would  react  when  presented 
with  an  opposing  asset  object.  NSS  allowed  multiple  behaviors  to  be  simulated 
concurrently  in  order  to  best  represent  real-world  actions  of  surface  ships,  UAVs,  and 
helicopters.  By  manipulating  the  behaviors  and  operating  rules  for  each  asset,  different 
scenarios  could  be  customized  to  suit  the  needs  of  each  individual  alternative.  For  a 
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complete  list  of  the  individual  object  tactics  and  their  associated  responses,  please  refer  to 
Table  15. 


Table  15.  Modeling  Tactics  by  Platform. 


Platform 

Tactic 

Tactic  Description 

Pirate  Skiffs 

Attack/Avoid  Air  T actic 

Attacks  blue  cargo  vessels  but  avoids  UAVS  or 
Naval  vessels  when  detected 

Cargo  ships 

Report  All  Tactic 

Reports  pirate  attacks  back  to  the  "cargo  base" 
to  spread  the  word  to  other  cargo  ships 

Naval  Vessels 

Anti-Piracy  Tactic 

Attacks  red  vessels  in  range  of  weapons  and 
also  includes  a  reporting  aspect  to  share  piracy 
detection  information  with  the  coalition  forces 

Pirate  Motherships 

Avoid  Air  Tactic 

Avoids  UAVS  or  Naval  vessels  when  detected 

UAVs 

Report  All  Tactic 

Reports  aerial  information  back  to  the  naval 
commander  about  asset  detections  and 
classifications  (blue  or  red  asset)  to  spread 
information  to  the  other  coalition  forces 

Airship 

Report  All  Tactic 

Reports  aerial  information  back  to  the  naval 
commander  about  asset  detections  and 
classifications  (blue  or  red  asset)  to  spread 
information  to  the  other  coalition  forces 

Interaction  tables  were  also  used  to  set  up  the  effectiveness  of  weapons  against 
different  classes  of  ships.  For  example,  small  deck  weapons  on  the  blue  assets  were 
given  a  probability  of  hit  (Ph)  of  around  0.8  for  the  larger  pirate  motherships,  and  a  lower 
Ph  of  around  0.4  for  the  smaller  pirate  skiffs.  Additionally,  the  pirate  skiffs  were  set  to 
be  un-attackable  with  larger  weapons,  such  as  harpoons,  which  would  essentially  be 
ineffective  in  a  real  world  scenario.  All  the  missile  capabilities  and  large  scale  weapons 
of  the  blue  alliance  were  considered  unrealistic  in  the  model  and  also  not  allowed  by 
international  law  for  use  against  suspected  pirates.  Due  to  this  reason,  the  Ph  of  all  large 
weapon  and  missile  capabilities  were  set  to  zero. 

Mission  plans  were  another  aspect  of  the  NSS  modeling  that  applied  to  UAV 

launches  and  pirate  skiff  launches.  In  order  for  the  surface  ships  (either  alliance)  to 

launch  a  secondary  craft,  mission  plans  needed  to  be  defined  in  order  to  specify  the 

timing  and  launch  conditions.  UAVs  were  launched  off  of  all  surface  craft  in  regular 

intervals,  with  a  rotating  pool  of  assets  to  keep  a  24  hour  surveillance  window.  LCS 
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ships  had  a  larger  pool  of  9  UAV  assets  (versus  other  naval  surface  ships)  in  order  to 
improve  availability  within  the  operating  zone.  Pirate  skiffs  were  launched  from  the 
mothership  upon  detection  of  a  cargo  ship  to  initiate  an  attack,  and  recalled  to  the 
mothership  upon  detection  of  an  opposing  blue  force  UAV  or  surface  ship. 

Model  objects  were  also  assigned  specified  motion  parameters  in  order  to  initiate 
realistic  interactions  in  the  scenarios.  The  motion  of  each  asset  is  described  in  Table  16 
below. 


Table  16.  Asset  Motion. 


Asset  Type 

Motion  Type 

Motion  Description 

Blue  Cargo  Ship 

Track 

355  cargo  ships  were  assigned 

fixed  motion  tracks  across  the 

Gulf  of  Aden  and  travelled  a 

repeating  path  back  and  forth. 

Red  Pirate  Motherships 

Area  Patrol 

Five  separate  pirate  operating 

areas  were  established 

throughout  the  Gulf  of  Aden  and 
20  pirate  motherships  were 
confined  to  patrol  each  area 
using  the  default  NSS  "patrol" 

function. 

Blue  Navy  &  Coalition  Ships 

Area  Patrol 

Five  separate  pirate  operating 

areas  were  established 

throughout  the  Gulf  of  Aden  and 

all  available  blue  assets  were 

spread  across  the  operating 
areas  in  order  to  patrol  for  red 
assets  using  the  default  NSS 
"patrol"  function. 

Blue  UAVs  and  helicopters 

Area  Patrol/Detect 

Mission  plans  were  used  to 

launch  all  aerial  vehicles  and  the 

vehicles  used  the  default  NSS 

aerial  "patrol"  function  to  detect 
and  classify  all  assets. 

Red  Pirate  Skiffs  (modeled  as 

aerial  vehicles  due  to  NSS 

constraints) 

Area  Patrol 

Mission  plans  were  used  to 
launch  the  pirate  skiffs  and  the 

skiffs  used  the  default  aerial 

"patrol"  function  to  attack  blue 
cargo  assets. 
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D.  RESULTS 

Because  of  the  inadvertent  loss  of  the  NSS  database  during  scenario  development, 
only  limited  data  for  three  out  of  the  four  scenarios  is  available  in  this  section.  The 
results  shown  below  in  Table  17,  MOE  Outputs,  indicate  that  there  were  no  large 
discernible  differences  between  the  effectiveness  of  the  Basic  OARS  system  and  the 
current  CTF-151  solution.  The  major  difference  that  the  model  did  indicate  was  that 
there  were  130,379  UAV  detections  compared  to  CTF-151's  91,179.  This  is  due  to  the 
fact  that  the  OARS  system  had  875  launches,  and  CTF-151  only  had  277. 

CTF-151  had  more  pirate  arrests  (overtakes)  than  the  OARS  system,  but  the 
OARS  system  used  its  UAV  presence  to  deter  pirates  from  attacking.  An  “aircraft  avoid 
tactic”  was  built  into  all  red  assets  in  the  NSS  models.  This  meant  that  the  modeled 
pirates  would  be  less  likely  to  commit  acts  of  piracy  if  they  spotted  the  surveillance 
UAVs  overhead.  Due  to  this  aspect  of  the  model,  the  fact  that  the  OARS  system  lowered 
the  amount  of  piracy  attempts  was  an  expected  outcome.  Additionally,  the  OARS  system 
was  slightly  more  effective  in  combating  pirate  motherships  in  terms  of  the  overtake 
percentage  MOE,  but  again,  the  system  utilizes  newer,  more  effective  LCS  ships  with 
better  weapons,  and  depends  more  on  UAV  presence  to  deter  piracy. 

One  of  the  major  MOEs  for  this  system  is  “percentage  detection  measurement.” 
OARS  performed  well  in  this  area  with  an  overall  average  number  of  detections  at 
130,379  versus  91,171  in  the  CTF-151  scenario.  This  indicates  that  further  research  into 
the  area  of  aerial  long  range  sensors  (such  as  those  on  the  hybrid  airship  in  the  OARS 
Augmented  scenario)  should  be  conducted  in  the  future  to  enhance  anti-piracy  efforts. 
The  presence  of  a  UAV  in  hostile  ocean  areas  appears  to  be  a  simple  deterrence  method 
to  combat  piracy.  Empirical,  quantitative,  research  methods  need  to  be  employed  in  the 
field  to  further  test  and  validate  the  effectiveness  of  this  deterrence  method. 
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Table  17.  MOE  Outputs  by  Scenario  and  MOE. 


Unopposed  Baseline  (3  replications) 

MOE  name 

Average 

Red  Assets  Destroyed  (Overtaken) 

0 

Blue  Assets  Destroyed  (Overtaken) 

57.7 

Red  Weapon  Launches  (Overtake  Attempts) 

123 

Blue  Weapon  Launches  (Overtake  Attempts) 

0 

CTF  151  (3  replications) 

MOE  name 

Average 

Red  Assets  Destroyed  (Overtaken) 

9.3 

Blue  Assets  Destroyed  (Overtaken) 

30.0 

Red  Weapon  Launches  (Overtake  Attempts) 

87.3 

Blue  Weapon  Launches  (Overtake  Attempts) 

27.7 

Blue  Surveillance  Classifications 

9937 

UAV  Cumulative  Launches 

277.3 

Blue  Surveillance  Detections 

91179.7 

Red  Successful  Overtake  %  (Derived  MOE) 

34.3% 

Blue  Successful  Overtake  %  (Derived  MOE) 

32.5% 

OARS  BASIC  (3  replications) 

MOE  name 

Average 

Red  Assets  Destroyed  (Overtaken) 

3 

Blue  Assets  Destroyed  (Overtaken) 

27.3 

Red  Weapon  Launches  (Overtake  Attempts) 

82.0 

Blue  Weapon  Launches  (Overtake  Attempts) 

6.7 

Blue  Surveillance  Classifications 

49223 

UAV  Cumulative  Launches 

875 

Blue  Surveillance  Detections 

130379.3 

Red  Successful  Overtake  %  (Derived  MOE) 

32.4% 

Blue  Successful  Overtake  %  (Derived  MOE) 

45.0% 

E.  MODEL  LIMITATIONS 

Some  limitations  associated  with  the  NS  S  software  constrained  the  team"s  ability 

to  simulate  the  OARS  concept  in  a  realistic  manner.  One  limitation  associated  with  the 

NSS  software  was  that  entering  new  MOEs  into  the  system  instead  of  utilizing  the  ones 

that  were  already  built  into  the  program  was  a  very  complex  process.  This  drove  the 

team  to  select  measurements  under  default  classes  available  within  NSS  such  as  asset 

destruction,  weapon  launches,  UAV  launches,  sensor  classifications,  and  sensor 

detections.  These  measurements  fit  well  with  the  stated  systems  engineering  process,  so 
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restrictions  on  MOE  data  was  not  a  big  issue.  Future  studies  in  the  area  of  anti-piracy 
systems  may  elect  to  customize  NSS  MOE  outputs  to  better  tailor  them  to  the  project 
requirements. 

The  NSS  software  is  based  on  traditional  naval  warfare  interactions  between 
known  enemies,  and  therefore  is  not  always  flexible  in  adapting  to  a  non-traditional  and 
evasive  enemy  like  pirates.  Since  the  pirates  often  use  evasive  tactics  such  as  disguising 
the  motherships  as  fishing  boats,  the  blue  asset  detection  characteristics  were  difficult  to 
model  realistically.  Often  in  the  scenario,  a  blue  force  asset  would  be  immediately  aware 
that  a  red  enemy  force  is  nearby  through  the  use  of  detection  sensors,  while  in  real  life, 
the  pirate  assets  are  difficult  to  identify  because  they  mix  in  so  well  with  normal 
merchant  traffic.  This  issue  was  somewhat  mitigated  by  using  a  timed  hostile  action  flag. 
Blue  vessels  were  not  allowed  to  engage  pirate  vessels  unless  a  hostile  action  had  taken 
place  within  a  set  amount  of  time.  This  feature  simulated  the  ability  of  the  pirates  to 
blend  back  into  the  background  traffic  if  they  were  not  engaged  quickly. 

Cargo/container  ships  were  difficult  to  model  within  the  scenarios  because  of  the 
sheer  number  of  transport  ships  that  operate  in  the  Gulf  of  Aden.  Exact  paths  for  ships 
were  difficult  to  model  because  of  the  variability  within  shipping  origin  ports  and 
destinations.  Therefore,  the  modeling  team  chose  to  simulate  1000  ship  crossings  over 
the  course  of  a  month  by  utilizing  500  blue  cargo  vessels  on  a  continuous  back  and  forth 
loop  in  areas  known  to  have  the  most  piracy.  The  actual  number  of  blue  cargo  vessels 
was  finalized  at  355  assets  because  of  NSS  memory  constraints,  but  the  team  has 
reasonable  assurance  that  at  least  1000  crossings  were  made  over  the  course  of  30  days  in 
all  four  scenarios  (since  each  scenario  had  at  least  3  crossings  through  the  Gulf  of  Aden 
by  each  cargo  ship). 

Other  limitations  included  a  limited  number  of  baseline  platforms  in  the  NSS 
database,  especially  when  it  came  to  new  classes  of  surface  ships  and  UAVs.  This  meant 
that  many  existing  platforms  had  to  be  extensively  modified  in  order  to  fit  the  operating 
parameters  of  the  new  platforms  like  the  LCS,  Dynalifter  Hybrid  Airship,  and  ScanEagle 
UAV.  Major  modifications  to  the  ship  object  properties  were  often  time  consuming  and 

many  times  led  to  NSS  software  run  errors  when  scenarios  would  be  replicated. 
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Refinement  of  the  new  object  properties  was  a  continual  process  in  order  to  ensure  that 
the  NS  S  simulations  ran  smoothly. 

Furthermore,  some  surface  assets,  such  as  pirate  skiffs,  needed  to  be  modeled  as 
aerial  assets  due  to  NSS  constraints  of  only  being  unable  to  launch  surface  craft  from 
surface  ships.  This  had  little  effect  on  the  interactions  within  the  model,  since  the  pirate 
skiffs  were  simply  modeled  as  UAVs  with  an  elevation  of  zero  and  the  ability  to  attack 
cargo  ships. 

In  conclusion,  although  there  were  limitations  to  the  NSS  software,  the  OARS 
team  was  able  to  produce  three  separate  scenarios  which  were  effective  in  depicting  the 
important  parameters  and  measuring  the  MOEs  related  to  real-world  piracy  interactions. 
The  NSS  software  package  was  only  partially  capable  of  modeling  the  real  world  piracy 
interactions,  and  it  was  instead  designed  more  for  traditional  warfare  between  two  known 
enemies.  Due  to  this,  a  more  flexible  software  package  may  be  required  in  the  future,  if 
research  is  continued  in  the  area  of  anti-piracy. 

F.  COST  ANALYSIS 

Each  OARS  alternative  is  comprised  of  subsystems  that  need  to  be  initially 
procured  from  existing  programs.  Costs  were  derived  from  published  documents  found 
from  the  respective  program  research.  Initial  costs  include  the  current  market  costs  of 
each  alternative  system  with  the  correct  inflation  indices  applied.  Procurement  of  future 
alternatives  to  replace  that  item  is  done  through  the  acquisition  strategy  using  an 
incremental,  technical  refresh  process.  The  initial  procurement  costs  account  for  the 
majority  of  funding  for  each  system. 

Future  year  spending  provides  a  method  of  determining  where  and  when  funding 
should  be  applied.  Inflation  rates  have  been  used  to  establish  out  year  costs,  and 
expected  costs  are  in  FY11  dollars.  Procurement  dollars  for  each  OARS  alternative 
decline  dramatically  after  the  first  two  years  due  to  the  fact  that  the  systems  will  be  fully 
acquired.  Additional  procurement  dollars  will  be  needed  later  in  the  OARS  altemative"s 
life  cycles  due  to  the  planned  acquisition  of  new  technology  during  the  technology 
refresh  periods. 
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1.  Cost  Assumptions 

Due  to  the  fact  that  the  OARS  alternative  systems  have  not  been  developed  or 
operated  in  a  combat  environment,  the  procurement,  operations,  and  support  costs  are  not 
yet  documented  for  analysis.  As  a  result,  all  cost  analysis  focused  exclusively  on  the 
individual  subsystems  within  the  OARS  alternatives  that  would  be  deployed  in  a  typical 
anti-piracy  mission. 

Exhaustive  research  was  conducted  to  find  a  Subject  Matter  Expert  (SME)  or 
credible  source  for  each  OARS  subsystem.  Data  collection  consisted  of  a  comprehensive 
research  effort  spanning  various  Navy  organizations  as  well  as  non-military 
organizations.  The  data  collected  was  comprised  of  pertinent  information  that  was 
unclassified  and  available  to  the  public.  Actual  costs,  SME  input,  confirmed 
specifications,  and  best  effort  estimates,  provided  inputs  to  the  OARS  cost  models.  By 
finding  the  SMEs  for  each  subsystem,  more  accurate  estimates  of  subsystem  costs  were 
made.  Additional  research  provided  unit  prices  and  system  specifications  (including  size, 
weight,  and  speed),  as  well  as  capability  estimates  based  on  current  systems  of  record. 
The  SMEs  were  able  to  either  provide  documentation  for  exact  costs  and  system 
specifications,  or  at  least  a  rough  estimate  for  the  respective  system.  Unknown  variables, 
such  as  integration  costs,  were  given  best  effort  analyses  to  determine  reasonable  cost 
ranges  on  existing  systems  of  record. 

During  the  modeling  and  simulation  phase  of  the  project,  the  OARS  team 
assumed  that  UAVs  would  be  utilized  for  only  detection  and  surveillance.  It  was 
assumed  that  detection  of  the  UAVs"s  presence  by  the  pirates  would  induce  them  to  halt 
their  aggression.  For  this  reason,  the  cost  calculations  did  not  include  weapon  systems 
aboard  the  UAV;  rather,  the  weapon  system  cost  was  added  to  the  pursuit  vessels  in  the 
form  of  mounted  .50  caliber  machine  guns.  Complete  UAV  system  Life  Cycle  Costs 
(LCC)  would  normally  be  critical  to  the  cost  comparisons  of  each  system"s  LCCs; 
however,  through  UAV  cost  research,  the  OARS  team  obtained  limited  data  which 
consists  of  an  hour-by-hour  cost  comparison  for  each  of  the  airborne  sensors.  The 
calculated  cost  of  UAV  support  was  derived  from  a  variety  of  sources  that  are 
documented  in  the  references  section.  Parametric  estimates  suggest  that  there  would  be 


95 


six  UAVs  aboard  each  host  vessel,  with  three  flying  at  all  times.  This  would  allow  an 
“around  the  clock”  detection  capability.  The  OARS  team  found  that  for  every  flight-hour 
that  each  UAV  was  flown,  there  would  be  a  corresponding  operating  cost  of 
approximately  $100  per-vehicle  (Defense,  Space  &  Security  2011). 

The  sub-systems  of  each  OARS  alternative  focused  on  existing  mature  technology 
and  the  strategies  that  have  been  adopted  to  support  those  technologies.  The  fielding  of 
these  mature  systems  allows  the  OARS  system  to  leverage  the  existing  U.S.  Navy  supply 
and  maintenance  infrastructure.  It  also  simplifies  the  components  of  training  and  helps 
facilitate  the  roles  of  both  the  Technical  Design  Agents  (TDA)  and  the  In-Service 
Engineering  Agents  (ISEA). 

Specific  consumables  and  non-lethal  interdiction  aids  were  not  included  in  the 
cost  assessment  as  they  are  procured  as  a  result  of  specific  threats  and  provided  to  system 
operators  to  carry  as  a  payload.  The  costs  associated  with  training  personnel  to  operate 
weapon  systems  and  sensor  packages  were  included  in  our  analysis.  Consumables  like 
ammunition,  dye  markers,  smoke  markers,  and  smoke-screen  bombs  used  during  training 
scenarios  were  included  in  the  life  cycle  costs  as  a  component  of  integration  and  disposal. 


a.  Life  Cycle  Costs 

The  total  cost  of  each  alternative  over  their  expected  lifetime  was 
determined  through  a  Life  Cycle  Cost  (LCC)  analysis.  It  provides  an  estimate  of  how 
much  funding  would  be  required  per  year  to  ensure  the  alternative  is  fully  operational. 
The  entire  profile  of  the  LCC  was  categorized  in  six  different  costs.  These  costs  are: 
procurement,  integration,  logistics,  operation,  maintenance,  and  disposal.  Both 
alternatives  had  an  individual  LCC  profile  that  was  examined  in  further  detail  below. 

The  length  of  each  OARS  alternative'^  life  cycle  was  a  result  of  several 
underlying  factors.  The  entire  life  cycle  can  be  broken  down  into  two  phases  with  the 
first  phase  seen  as  the  systenf's  acquisition.  This  depends  on  how  quickly  the  assets  can 
be  procured  and  integrated,  as  well  as  how  much  funding  will  be  logically  appropriate 
during  that  time  period.  The  second  phase  was  the  actual  operational  life  cycle  of  the 
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systems.  This  includes  the  logistics,  operation,  maintenance,  and  disposal  costs 
associated  with  fielding  the  systems.  During  each  year  of  the  life  cycle  it  was  assumed 
that  there  will  be  on  average  365  missions  per  year  with  24  hour,  unceasing  service  on 
each  mission  day.  The  life  of  the  system  was  evaluated  based  upon  the  lifecycles  of  the 
corresponding  subsystems.  The  mature  elements  that  are  weaved  into  the  OARS  system 
supported  the  15  year  fielding  plan  with  technical  refresher  cycles  to  be  planned  in  2025 
and  2030.  The  end  of  life  for  both  alternative  systems  is  expected  to  be  2035. 

2.  Cost  Analysis  and  System  Specification  Methodology 

The  rendered  alternatives  that  were  deemed  feasible  were  given  a  comparative 
cost  benefit  analysis  to  determine  how  much  capability  could  be  provided  and  at  what 
cost.  The  cost  of  each  alternative  was  examined  from  multiple  perspectives.  Unit  price, 
estimated  integration  costs,  manpower  costs,  and  many  other  cost  components  were  used 
to  determine  relative  alternative  costs. 

Spreadsheet  tools  were  used  to  capture  system  data  and  analyze  both 
mathematically  and  graphically  the  relationships  and  relative  costs  between  system 
alternatives.  The  costs  were  categorized  as  procurement  costs  and  life  cycle  costs.  The 
costs  of  the  two  OARS  alternatives  were  also  broken  out  by  their  corresponding 
functional  objectives.  This  data  can  be  found  in  Appendix  I. 

In  order  to  generate  a  cost  estimate  for  a  single  alternative,  the  cumulative  costs  of 
the  subsystems  were  accounted  for  as  accurately  as  possible.  A  15  year  life  cycle  cost 
(LCC)  analysis  was  performed  for  each  of  the  two  OARS  alternatives.  A  spiral  and 
incremental  procurement  strategy  was  employed  and  included  as  an  acquisition  cost 
category  for  the  LCC  analysis.  In  2025  and  2030,  an  incremental  technical  refresh  was 
scheduled  to  occur  in  order  to  make  the  OARS  lifecycle  more  realistic. 


a.  Preferential  Model  Results 

Each  alternative  component  (element)  was  selected  by  using  a  multiple 
criteria  preference  model.  Each  objective  was  broken  down  into  key  attributes  by 

stakeholder  preferences.  The  preference  model  can  be  found  in  Appendix  G. 
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The  result  is  that  the  Zodiac  Rigid  Hull  Inflatable  Boat  (RHIB)  was  the 
best  alternative  to  use  in  both  of  the  OARS  systems.  Similarly,  the  same  technique  was 
also  utilized  for  evaluating  what  the  best  lightweight  UAV  would  be.  These  lightweight 
UAVs  were  to  be  used  for  surveillance  in  both  OARS  alternatives.  The  model  resulted  in 
the  ScanEagle  UAV  arising  as  the  most  preferred,  mostly  due  to  its  very  long  endurance 
and  range.  A  preferential  model  was  also  developed  for  the  Heavy  UAV  BAMS  system 
that  was  to  be  used  in  the  Augmented  OARS  alternative.  This  resulted  in  the  MQ-4 
Global  Hawk  being  chosen  as  the  best  BAMS  alternative  to  model  in  the  Augmented 
OARS  cost  analysis. 

3.  Cost  of  Alternative  #1,  Basic  OARS 
a.  Procurement  Costs 

The  total  procurement  cost  of  Alternative  1,  Basic  OARS,  was  found  to  be 
$4.78  billion.  Costs  for  Alternative  1,  Basic  OARS,  include  funding  for  combat  systems, 
air-borne  sensor  packages,  surface  sensors,  and  weapon  systems.  Combat  systems 
include  command  and  control  consoles,  as  well  as  communication  devices.  Table  18 
shows  Alternative  l"s  procurement  cost  breakdown.  The  data  shows  that  the  bulk  of 
Alternative  l"s  procurement  costs  center  around  its  use  of  six  individual  Littoral  Combat 
Ships  (LCS)  systems. 


Table  18.  Procurement  Cost  Breakdown  for  Alternative  1. 


Item 

Acquisition 

in  $  Millions 

Percentof  Total 

Host  Vessels:  LCS  Ships 

$ 

4,080.00 

88.83% 

UAV's 

$ 

1.32 

0.03% 

SH-60s 

$ 

509.00 

11.08% 

Pursuit  Vessels:  RHIBs 

$ 

0.90 

0.02% 

50 Cal  MG 

$ 

2.03 

0.04% 

Total  Acquisition 


$ 


4,593.25 
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b.  Life  Cycle  Costs 

Table  19  illustrates  a  similar  table  that  highlights  the  total  LCC  of 
Alternative  1.  The  total  LCC  of  Alternative  1  comes  to  $15.5  billion.  Similar  to  the 
procurement  numbers,  the  LCS  ships  and  SH-60  Helicopters  account  for  the  majority  of 
the  LCC  for  Alternative  1 . 


Table  19.  LCC  Breakdown  for  Alternative  1. 


Item 

LCC  in  $  Mill  ions 

Percent  of  Total 

Host  Vessels:  LCS  Ships 

$ 

7,980.00 

51.45% 

UAV's 

$ 

773.43 

4.99% 

SH-60s 

$ 

6,048.30 

39.00% 

Pursuit  Vessels:  RHIBs 

$ 

704.97 

4.55% 

50 Cal  MG 

$ 

2.54 

0.02% 

15,509.23  | 


Total  LCC 


Figure  30  illustrates  a  breakdown  of  the  total  LCC  of  each  of  Alternatives 
l"s  subsystems.  As  noted  previously,  the  LCS  and  SH-60  Helicopter  systems  account  for 
the  majority  of  the  costs. 
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Figure  30.  LCC  Breakdown  of  Alternative  V%  Subsystems. 


Figure  31  shows  the  funding  cycle  of  Alternative  l"s  lifecycle.  The  figure 
shows  an  initial  spike  in  funding  with  a  gradual  increase  of  funding  throughout  the 
fielding  process.  The  acquisition  phase  will  take  place  within  the  first  five  years.  The 
largest  amount  of  funding  throughout  the  entire  life  cycle  will  come  during  the  second 
year  with  nearly  $2,591  billion  appropriated  towards  23%  of  the  total  initial  procurement 
costs  and  20.5%  of  the  initial  integration  costs. 
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Figure  31.  LCC  of  Alternative  1. 


The  fielding  phase  will  begin  in  year  2020  with  approximately  $440 
million  appropriated  to  logistics,  maintenance,  and  operational  costs.  Each  year  beyond 
that,  costs  in  each  area  will  gradually  increase  until  2032  with  a  total  cost  just  over  $450 
million.  The  subsequent  year  will  see  a  decrease  in  operational  costs  due  to  a  reduction 
in  training  needs.  The  year  2033  will  be  the  first  year  that  maintenance  costs  are  cut,  but 
it  will  also  be  the  first  year  that  disposal  costs  are  applied.  The  final  year  will  consist 
solely  of  disposal  and  logistics  costs.  Throughout  the  entire  fielding  phase  of  the  life 
cycle,  the  logistics  costs  will  increase  at  a  constant  rate. 

The  two  additional  funding  spikes  that  are  shown  in  Figure  3 1  will  come 
during  the  technical  refresh  installments,  which  were  planned  to  occur  in  2025  and  2030. 
Nearly  $500  million  in  technical  refresh  costs  will  be  spent  in  the  first  technical  refresh 
period  of  2025.  Similarly,  almost  $620  million  will  be  spent  during  the  second  technical 
refresh  year  of  2030. 
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Costs  for  the  acquisition  phase  and  fielding  phase  in  Alternative  1  are 
quite  similar  even  though  one  phase  is  five  years  and  the  other  is  15  years.  A  distribution 
of  cost  categories  for  LCC  is  displayed  on  Figure  32.  The  figure  shows  that  the 
acquisition  phase  represents  39%  of  the  total  costs  while  the  cost  for  the  fielding  phase 
accounts  for  the  remaining  61%.  Initial  procurement  and  the  procurement  for  the 
technical  refresh  integration  is  the  largest  cost,  at  nearly  $4.8  billion.  Logistics  makes  up 
exactly  one  third  of  the  total  cost  with  almost  $3.6  billion  allocated  towards  it.  The 
integration  portion  is  set  at  9%  which  accounts  for  $730  Million.  This  correlates  well 
with  legacy  integration  efforts  utilized  during  the  10  year  development  of  technology 
upgrades  for  the  Apollo  project.  This  integration  effort  has  been  well  documented  by 
NASA  and  this  data  was  utilized  by  the  OARS  team  to  help  define  integration  costs  of 
the  OARS  system  (National  Aeronautics  and  Space  Administration  2011,  678). 
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Figure  32.  Alternative  1  LCC. 
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The  OARS  team  determined  that  the  requirements  for  manning  the  system 
will  consist  of  utilizing  45  sailors  per  watch  shift.  Furthermore,  it  is  assumed  that  there 
will  be  three  separate  watch  shifts,  each  consisting  of  8  hour  periods  (Douangaphaivong 
2004,  pg  60).  The  maintenance  and  disposal  costs  are  relatively  minor  compared  to  the 
other  four  cost  categories,  but  still  need  to  be  considered  when  determining  the  overall 
LCC. 


4.  Cost  of  Alternative  #2,  Augmented  OARS 
a.  Procurement  Costs 

A  procurement  cost  breakdown  for  Alternative  2  is  shown  in  Table  20. 
The  table  shows  that  Alternative  2"s  procurement  cost  is  roughly  $5  billion.  Just  as  with 
Alternative  1,  Alternative  2"s  total  funding  amount  is  largely  affected  by  the  procurement 
cost  of  the  host  ship  platforms.  However,  the  addition  of  Alternative  2"s  BAMS  system 
increases  the  procurement  cost. 


Table  20.  Procurement  Cost  Breakdown  of  Alternative  2 


Item 

Acquisition 

in  $  Millions 

Percent  of  Total 

Host  Vessels:  LCS  Ship 

$ 

4,080.00 

81.06% 

UAV's 

$ 

1.32 

0.03% 

SH-60 

$ 

509.00 

10.11% 

Pursuit  Vessels:  RHIBs 

$ 

0.90 

0.02% 

50  Cal  MG 

$ 

2.03 

0.04% 

BAMS 

$ 

440.00 

8.74% 

Total  Acquisition  $ 


5,033.25 


b.  Life  Cycle  Costs 

The  breakdown  of  Alternative  2"s  LCC  is  shown  in  Table  21.  The  data 
shows  that  Alternative  2"s  LCC  estimated  at  just  under  $17.7  Billion. 
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Table  21.  LCC  Cost  Breakdown  of  Alternative  2. 


Item 

LCC  in  $  Millions 

Percentof  Total 

Host  Vessels:  LCS  Ships 

$ 

7,980.00 

44.90% 

UAV's 

$ 

773.43 

4.35% 

SH-60s 

$ 

6,048.00 

34.03% 

Pursuit  Vessels:  RHIBs 

$ 

704.97 

3.97% 

50 Cal  MG 

$ 

2.54 

0.01% 

BAMS  UAV 

$ 

2,262.00 

12.73% 

17,770.93  | 


Total  LCC 


$ 


A  breakdown  of  costs  for  each  year  of  Alternative  2  life  cycle  is  shown  in 
Figure  33.  The  second  and  third  years  of  the  acquisition  phase  account  for  the  two  largest 
funding  years  during  the  life  cycle  of  the  system.  Allocation  of  funding  in  2017  will 
come  to  just  over  $2.03  billion,  while  costs  in  2018  will  come  to  just  over  $1.35  billion. 
The  fielding  phase  will  begin  in  year  2020,  with  $429  million  appropriated  to  logistics, 
maintenance  and  operational  costs.  Each  year  beyond  that,  costs  in  each  area  will 
gradually  increase  until  2032,  which  has  a  total  cost  just  over  $497.5  million.  The 
subsequent  year  will  see  a  decrease  in  operational  costs  due  to  a  reduction  in  training 
needs.  The  year  2033  will  be  the  first  year  that  maintenance  costs  are  cut,  but  it  will  also 
be  the  first  year  that  disposal  costs  are  applied.  The  final  year  will  consist  solely  of 
disposal  and  logistics  costs.  Throughout  the  entire  fielding  phase  of  the  life  cycle,  the 
logistics  costs  increase  at  a  constant  rate. 

The  two  additional  funding  spikes  that  are  shown  in  Figure  33  will  come 
during  the  technical  refresh  installments.  Nearly  $599  million  in  technical  refresh  costs 
will  be  spent  in  2025,  which  is  the  first  year  of  installation,  and  almost  $824  million  will 
be  spent  during  the  second  installation  year  of  2030. 
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Figure  33.  LCC  of  Alternative  2. 


Figure  34  shows  a  breakdown  of  Alternative  2"s  LCC  per  each  of  its 
subsystems.  The  data  shows  that  the  majority  of  the  LCCs  center  around  the  LCS  ships 
and  the  SH-60  Helicopters,  although  the  introduction  of  the  BAMS  UAV  adds  $2,262 
Billion  to  the  LCC  that  was  not  a  part  of  Alternative  1 . 
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Figure  34.  LCC  Breakdown  of  Alternative  2f<s  Subsystems. 


A  distribution  of  cost  categories  for  Alternative  2"s  LCC  is  displayed  on 
Figure  35.  The  acquisition  phase  represents  39%  of  the  total  LCC  cost  while  the  cost  for 
the  fielding  phase  accounts  for  the  remaining  61%. 
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Figure  35.  Alternative  2  LCC. 


5.  Cost  of  the  Status  Quo,  CTF-151 

Defining  the  exact  cost  of  operating  CTF-151  was  a  very  challenging  task  for  the 
OARS  team.  The  main  issue  is  that  the  force  structure  of  CTF-151  fluctuates  constantly. 
CTF-151  has  matured  over  its  2  years  of  operation,  but  there  still  is  not  a  baseline  force 
structure  to  have  as  a  point  of  reference.  CTF-151  is  a  voluntary  force  comprised  of 
many  countries  that  provide  ships,  aircraft,  and  support  in  anti-piracy  operations  when 
they  can.  In  order  to  predict  the  LCC  of  CTF-151,  one  would  have  to  know  the  exact 
number  of  ships  at  any  point  in  time.  After  performing  a  great  deal  of  research  and 
talking  with  stakeholders,  the  OARS"  modeling  and  simulation  team  decided  to  model 
CTF-151  as  containing  14  ships.  Four  of  the  ships  were  assumed  to  be  USN  assets.  The 
four  U.S.  Naval  forces  were  modeled  as: 

•  DDG-51  Destroyer 

•  FFG-7  Frigate  (Quantity  -  2) 

•  LPD-17  Amphibious  Transport  Dock. 
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CTF-15  l'rs  ten  remaining  coalition  vessels  were  assumed  to  consist  of  the 
following  ships: 

•  Jianwei  frigate  from  PRC  (China)  (Quantity  -  2) 

•  Ulsan  frigate  from  South  Korea 

•  Barbaras  frigate  from  Turkey  (Quantity  -  3) 

•  La  Fayette  frigate  from  Singpore  (Quantity  -  2) 

•  Iroquois  destroyer  from  Canada 

•  Floreal  frigate  from  France. 

In  order  to  be  consistent  with  the  modeling  and  simulation  effort,  the  cost  analysis 
also  used  this  same  force  structure  when  estimating  the  LCC  of  CTF-15 1. 

Another  reason  that  estimating  the  cost  of  CTF-15 1  is  difficult  is  the  fact  that 
most  of  the  assigned  ships  are  from  foreign  navies  and  therefore,  data  on  their  life  cycle 
costs  is  not  readily  available.  For  this  reason,  the  OARS  team  utilized  the  same  life  cycle 
costs  that  were  used  in  the  cost  estimation  efforts  of  the  two  OARS  alternatives.  These 
life  cycle  costs  were  for  USN  assets,  but  due  to  the  fact  that  the  foreign  navy  ships  have 
similar  sizes  and  anti-piracy  missions,  the  assumption  was  made  that  the  foreign  ships 
would  have  similar  LCCs. 

Table  22  shows  a  breakdown  of  the  estimated  LCC  of  CTF-151.  The  appropriate 
number  of  helicopters,  RHIB  boats,  and  the  occasional  UAVs  were  also  added  to  the 
CTF-151"s  LCC  model.  The  LCCs  of  the  helicopters  were  for  USN  SH-60  Helicopters. 
The  OARS  team  made  the  assumption  that  the  LCCs  of  foreign  helicopters  would  be 
similar  to  the  known  USN  figures.  The  total  LCC  was  estimated  at  $17.47  Billion. 
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Table  22.  CTF-151  LCC  Cost  Analysis. 


CTF-151 

Ship 

Qty 

Cost  per 
Ship  ($B) 

Total 

Acquisition 
cost  ($B) 

Added  Item  LCC  Costs 
{RHIB,  UAV,  Helo){$B) 

Total  LCC 
($M) 

DDG-51 

1 

$1.5050 

$1.5050 

$0.0882 

$3,084.59 

FFG-7 

2 

$0.6710 

$1.3420 

$0.0008 

$3,042.00 

LPD-17# 

1 

$1.2050 

$1.2050 

$0.0002 

$1,649.44 

Jianwei 

2 

$0.1540 

$0.3080 

$0.0008 

$697.00 

Ulsan 

1 

$0.1190 

$0.1190 

$0.0002 

$134.70 

Barbaros 

3 

$1.0140 

$3.0420 

$0.0272 

$5,901.48 

La  Fayette 

2 

$0.3100 

$0.6200 

$0.0178 

$1,421.31 

Iroquois 

1 

$1.1590 

$1.1590 

$0.0119 

$1,323.12 

Floreal 

1 

$0.1860 

$0.1860 

$0.0122 

$223.97 

Total  Acquisition  Cost 

$9,645.28 

Total  CTF-151  LCC 

$17,477.61 

G.  ALTERNATIVE  COMPARISON 
1.  LCC  Comparison 

Figure  36  shows  a  life  cycle  cost  comparison  of  both  the  OARS  alternatives  and 
CTF-151.  CTF-151  was  estimated  to  have  the  highest  life  cycle  cost.  Alternative  1, 
OARS  Basic,  was  estimated  to  have  the  lowest  LCC.  Due  to  Alternative  2"s  addition  of  a 
heavyweight  BAMS  UAV,  its  life  cycle  cost  was  greater  than  Alternative  1 . 
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Figure  36.  Life  Cycle  Cost  Comparison 


2.  Cost-Value  Analysis 

a.  Decision  Matrix 

A  decision  matrix  was  used  to  combine  value  scores,  global  weights,  and 
raw  data  and  produce  total  value  scores  for  each  alternative  based  on  the  most  basic 
additive  form,  or  weighted  summation,  of  the  value  function  Multi- Attribute  Value 
Theory.  In  the  additive  form,  the  function  (U)  is  split  into  several  different  functions  (Ui) 
which  are  strictly  increasing  real  functions.  The  function  (U)  can  then  be  retrieved  by 
adding  the  sub-functions  (Ui).  Global  weights  were  derived  from  Figure  12  of  the  QFD 
analysis  which  states  objectives  for  the  system.  However,  since  modeling  outputs  from 
NSS  did  not  match  up  exactly  to  the  QFD  outputs,  estimates  were  made  for  global 
weights  that  best  matched  up  to  the  objective  outputs  of  Figure  12.  These  global  weights 
were  then  outlined  in  Table  23.  The  measures  in  the  right  hand  column  of  the  matrix 
were  pulled  from  the  NSS  modeling  MOE  outputs.  The  OARS  Augmented  system  was 
not  included  in  this  decision  matrix  because  there  were  no  NSS  MOE  outputs  available  to 
analyze. 


110 


Table  23.  Decision  Matrix. 


Measure 

Global  Weight 

Alternatives 

Unopposed 

CTF  151 

OARS  Basic 

UAV Total  Detections 

0.3 

0 

0.7 

1 

UAV  Total 

Classifications 

0.3 

0 

0.2 

1 

UAV  Cumulative 

Launches 

0.1 

0 

0.32 

1 

Bl  ue  Assets  Overtaken 

0.25 

0 

0.93 

1 

Red  Assets  Overtaken 

0.05 

0 

1 

0.34 

Total  Value  Score 

1 

0 

0.58 

0.96 

As  seen  above,  the  OARS  Basic  ranks  highest  with  a  Total  Value  Score  of 
0.96.  CTF  151  has  the  second  highest  total  value  score  of  0.58.  Since  the  OARS  Basic 
system  scores  higher  than  CTF  151  in  four  out  of  the  five  measures  of  effectiveness 
(MOEs)  it  was  determined  that  no  sensitivity  analysis  was  required.  The  goal  of  both 
CTF  151  and  OARS  is  to  deter  piracy,  so  overtaking  (red)  pirate  ships  will  never  be 
assigned  a  global  weight  high  enough  to  greatly  influence  the  CTF  151  Total  Value 
Score. 


b.  Cost  versus  Value 

Cost-value  analysis  was  performed  to  consider  the  overall  value,  with 
respect  to  effectiveness.  By  plotting  the  total  value  score  obtained  from  the  decision 
matrix  in  Table  23  against  the  system  acquisition  costs  from  the  cost  analysis, 
relationships  between  cost  and  performance  can  be  derived  from  the  alternatives.  When 
an  alternative  has  a  higher  overall  cost  and  a  lower  total  value  score  than  another 
alternative  it  is  considered  “dominated”  by  that  alternative.  The  OARS  Augments 
system  was  not  included  in  this  analysis  because  the  purpose  of  the  analysis  was  only  to 
compare  alternatives  with  available  M&S  MOE  outputs. 
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Table  24.  Cost  versus  Effectiveness  Data. 


Alternative 

LCC  Cost  (US  $  billions) 

Total  Value  Score 

Unopposed 

$0.00 

0 

CTF 151 

$17,477.61 

0.58 

Alternative  1:  OARS 

Basic 

$15,509.23 

0.96 

Alternative  2:  OARS 
Augmented 

$17,770.93 

Undetermined 

The  data  from  Table  24  above  was  then  used  to  create  the  graph  presented 
in  Figure  37  below. 
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Figure  37.  Cost  versus  Effectiveness  Comparison. 
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Figure  37  illustrates  that  OARS  Basic  is  the  preferred  alternative,  since  it 
dominates  the  CTF  solution  with  both  a  lower  cost  and  higher  value  score. 

G.  LOGISTICAL  SUPPORT  ANALYSIS 

The  document  OPNAV  4000.85  (1986)  addresses  U.S.  Naval  systems  logistics 
and  breaks  down  logistics  into  three  areas.  These  are:  Acquisition  Logistics,  Integrated 
Logistics  Support  (ILS),  and  Operational  Logistics. 

1.  Acquisition  Logistics 

Acquisition  logistics  was  simplified  by  design.  Existing  commercial  UAV 
technology  was  utilized.  The  ScanEagle  is  also  a  complete  system  package  in  itself.  It  is 
the  aircraft,  the  launcher,  the  recovery  system,  and  the  ground  control  station.  It  has  been 
fielded  for  years  and  flown  numerous  sorties  from  land  as  well  as  shipboard  bases  of 
operation.  An  LCS  host  vessel  was  selected  because  of  its  mission  modularity  and 
perfect  suitability  for  UAV  operations.  The  UAV  JP-5  fuel  requirement  is  already 
handled  by  the  LCS  JP-5  fueling  system  currently  in  place.  The  OARS  support  strategy 
uses  a  previously  documented  Performance-Based  Logistics  Strategy  and  makes  it  easier 
to  focus  on  performance  rather  than  the  product.  High  failure  items  have  already  been 
identified  for  spares.  Common  Off  the  Shelf  (COTS)  items  are  being  used  as  much  as 
possible  as  well  as  Naval  Inventory  Control  Point  (NAVICP)  on-board  sparing  and  Navy 
or  Commercial  maintenance  chains.  The  use  of  emerging  technologies  is  discouraged. 

2.  Integrated  Logistics 

Integrated  Logistics  Support  (ILS)  for  U.S.  Navy  Programs  involves  all  of  the 

support  considerations  necessary  to  ensure  effective  and  economical  support  for  the  life 

cycle  of  ships,  systems,  and  equipment.  Because  the  OARS  system  consists  of  existing 

fielded  and  proven  technologies  and  platforms,  the  ILS  management  process  will  be 

expedited.  This  process  will  involve  developing  support  requirements  consistent  with  the 

design  and  other  requirements,  integrating  these  considerations  into  the  design,  and 

providing  the  required  support  during  the  system  or  equipment  life  cycle  at  minimum 

cost.  The  in  service  engineering  group  is  to  also  produce  all  hardware  technical 
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documents  as  well  as  OARS  mission  operations,  associated  systems  integration  and 
interactions,  and  all  maintenance  requirements.  These  will  be  produced  with  contractor 
support  using  pre-existing  commercial  documentation,  pre-existing  LCS  module 
documentation,  as  well  as  any  new  original  documentation  as  needed. 

3.  Operational  Logistics 

Operational  logistics  consists  of  logistical  and  other  support  activities  required  to 
support  the  OARS  system  during  mission  operations.  OARS  is  a  user  maintained  system. 
A  goal  of  OARS  is  to  reduce  depot  level  maintenance  as  much  as  possible.  Initial 
operational  and  maintenance  training  will  be  conducted  through  the  ScanEagle  vendor's 
training  services.  Eventually  the  Navy  will  conduct  its  own  training  as  system  familiarity 
increases.  Intermediate  depot  level  maintenance  will  be  provided  when  necessary.  For 
parts  support,  a  Consolidated  Shipboard  Allowance  List  (COSAL)  will  be  developed  to 
support  routine  maintenance  as  well  as  active  mission  repairs.  Again,  the  operational 
logistics  development  will  be  assisted  by  the  fact  that  these  UAV  packages  already  exist 
in  the  fleet. 

4.  Integration 

As  stated  above,  the  LCS  host  ship  concept  was  chosen  because  of  its  modular 

mission  construction  and  its  ability  to  carry  enough  UAVs  needed  to  carry  out  the  OARS 

swarm  UAV  missions.  It  can  also  support  an  SH-60  helicopter.  There  is  plenty  of  room 

for  the  ground  control  station  as  well  as  launch  and  recovery  platforms.  Hangar  space 

allows  for  efficient  storage  of  UAVs  in  vertical  racks.  The  JP-5  fuel  of  the  ScanEagle 

will  be  supplied  by  the  existing  JP-5  fueling  stations.  There  is  space  for  the  multiple 

launchers  necessary  to  get  as  many  UAVs  airborne  into  the  air  as  possible  in  support  of  a 

swarm  mission  requirement.  Launchers  as  well  as  recovery  hooks  will  be  positioned 

along  the  rail  of  the  LCS.  This  way,  a  returning  aircraft  does  not  have  to  cross  over  the 

deck,  which  creates  a  safer  operational  environment.  Since  the  UAVs,  launcher,  ground 

control  station,  and  recovery  system  comes  as  a  package,  this  subsystem  is  already 

integrated.  This  includes  the  hardware,  weapons,  communication,  and  sensor  payloads  as 

well  as  the  software  and  databases.  All  of  the  above  will  tend  to  reduce  the  overall  cost 
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of  integration.  The  cost  of  labor  (number  of  tasks,  number  of  workers,  salary,  number  of 
man-hours  for  each  task)  will  be  estimated  by  Subject  Matter  Experts  (SME). 

5.  Logistics  Support  and  Supply  Chain 

The  OARS  system  will  be  used  to  protect  vessels  of  all  nations  and  therefore 
funding  for  acquisition  and  sustainment  will  depend  on  international  assistance.  This 
process  is  defined  in  DoD  7000. 14-R  “International  Acquisition  and  Cross  Servicing 
Agreements”  (2011).  The  sustainment  program  will  be  one  of  cooperation  with  all 
member  states.  As  previously  mentioned,  the  OARS  system  will  be  using  existing  DoD 
logistics  infrastructure.  An  ISEA  and  Logistics  center  will  be  identified.  It  will  make  use 
of  the  current  parts  ordering  system,  have  a  Coordinated  Shipboard  Allowance  List 
(COSAL)  system  in  place  for  on-board  sparing  for  deployment  maintenance  and  repair, 
and  follow  the  current  parts  storage  policies.  Depot  level  maintenance  will  be  reduced  as 
much  as  possible.  A  repair  policy  will  be  established.  On-site  logistics  and  repair 
support  unique  to  the  ScanEagle  subsystem  package  will  be  provided  by  the  vendor  under 
a  service  level  contract. 

6.  Operational  and  Maintenance  Manpower 

The  OARS  system  will  have  a  basic  anti-piracy  mission  module  consisting  of  the 

ScanEagle  subsystem  package,  detention  facilities  for  prisoner  transport,  and  SH-60 

helicopter  operations.  Typically,  an  LCS-2  with  basic  modules  requires  40  core  crew 

members  which  includes  all  enlisted  and  officer  personnel  and  up  to  35  mission  specific 

personnel.  The  OARS  system  will  have  four  ground  control  operators  per  8  hour  shift  for 

a  total  of  13  onboard  operators  to  handle  a  24  hour  mission,  with  one  as  a  backup.  There 

will  be  an  additional  13  onboard  launch  and  recovery  personnel  as  well.  The  SH-60  crew 

needs  will  include  3  pilots,  3  co-pilots  and  3  aviation  warfare  systems  operators. 

Initially,  training  for  each  OARS  system  includes  UAV  manufacturer-provided  courses. 

Ten  weeks  for  each  UAV  operator,  four  weeks  for  each  maintenance  personnel,  and  an 

additional  six  week  course  which  will  train  personnel  to  become  instructors  themselves. 

This  will  allow  the  Navy  to  conduct  its  own  training  in  the  future.  Students  will  be 

recruited  early  enough  to  serve  as  each  OARS  system  is  readied  for  service.  Student 
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requirements  will  include  computer  skills  and  physical  dexterity.  The  cost  of  training  is 
identified  in  the  life  cycle  cost  estimates  in  this  report. 


7.  Disposal  and  Demilitarization 

Following  the  guidelines  in  DOD  4160.21-M  “Defense  Material  Disposition 
Manual”  (1997),  the  OARS  Project  Manager  must  document  all  demilitarization  and 
disposal  requirements.  The  cost  estimates  for  this  process  will  be  provided  early  on.  The 
demilitarization  plans  will  contain  the  following  information  for  each  item  to  be  disposed 
of: 


1.  The  item  name. 

2.  How  the  item  functions  when  used  as  intended. 

3.  Constituent  parts  of  the  item  and  its  components. 

4.  How  to  disassemble  and  demilitarize  the  item  and  its  components. 

5.  Safety  requirements  related  to  the  item  and  to  the  demilitarization  process  for 
the  item. 

6.  Environmental  considerations  and  liabilities  associated  with  the  disassembly, 
demilitarization  and  disposal  processes  (meets  environment,  safety  and 
occupational  health  (ESOH)  requirements. 

OARS  subsystems,  equipment,  components,  and  parts  may  also  be  removed  and 
replaced  because  of  obsolescence,  failures,  changes,  or  improvements.  These  items,  once 
removed,  may  be  remanufactured,  repaired,  reused,  refurbished,  or  demilitarized  and 
disposed  of  at  the  organizational,  intermediate,  or  depot  level  maintenance  activity. 
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V.  CONCLUSIONS  AND  RECOMEND ATIONS 


A.  CONCLUSIONS 

After  all  analysis  was  complete,  the  team  found  that  the  OARS  Basic  system 
provides  the  most  detections  of  pirates  and  is  the  cheapest  to  operate.  For  these  reasons, 
the  OARS  Basic  system  is  the  recommended  anti-piracy  solution. 


1.  Modeling  and  Simulation  Conclusions 

The  modeling  and  simulation  effort  showed  that  OARS  Basic,  which  had  130,379 
pirate  detections,  was  better  at  detecting  pirates  than  the  modeled  CTF-151  solution, 
which  had  91,171  detections.  This  was  a  43%  increase  in  detection.  Early  detection  of 
pirate  activity  is  crucial  to  its  prevention.  The  stakeholders  felt  adamantly  that  weapons 
should  not  be  implemented  onto  the  UAVs,  but  instead,  precise  surveillance  capabilities 
should  be  created.  This  is  because  pirate  interdiction  is  not  occurring  in  a  wartime 
environment,  which  means  that  friendly  forces  cannot  engage  pirates  with  deadly  force 
unless  it  is  for  self-defense  purposes.  The  43%  increase  in  detections  equaled  39,208 
more  detected  pirates. 

The  modeling  results  did  show  that  CTF-151  had  more  pirate  arrests  than  the 
OARS  Basic  system,  but  this  was  an  expected  result  due  to  the  fact  that  the  pirates  were 
less  deterred  and  freer  to  commit  acts  of  piracy.  The  OARS  Basic  system"s  use  of 
lightweight  UAVs  gives  it  superior  surveillance  and  reconnaissance  capability,  as  well  as 
a  greater  ability  to  capture  incriminating  evidence  of  pirate  acts.  The  addition  of  video 
surveillance  data  will  allow  more  pirates  to  be  prosecuted  for  their  acts  of  piracy. 


2.  Cost  Analysis  Conclusions 

The  total  Life  Cycle  Cost  of  the  two  OARS  alternatives  and  the  CTF-151  solution 

was  estimated.  After  the  cost  analysis  was  complete,  the  OARS  Basic  system  was  found 

to  be  the  cheapest  alternative,  and  had  a  life  cycle  cost  that  was  13%  cheaper  than  the 

CTF-151  solution.  The  OARS  Basic  system  was  cheaper  because  it  utilizes  UAV 

technology  to  cover  a  greater  area  and  therefore,  requires  fewer  high-value  ships  than  the 
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CTF-151  solution.  The  OARS  Basic  system  is  also  comprised  of  the  newer  Littoral 
Combat  Ships  (LCS)  that  have  a  much  smaller  life  cycle  cost  than  today"s  naval  ships. 

3.  Decision  Metrics  Conclusions 

Figure  38  shows  the  decision  metrics  matrix  that  defines  the  modeling  and 
simulation  Measures  of  Effectiveness  (MOE)  as  well  as  their  global  weight.  Due  to  the 
crash  of  the  modeling  and  simulation  software  database,  the  Naval  Simulation  System 
(NSS),  all  modeled  scenarios  and  results  were  deleted  and  lost  before  the  OARS  team 
had  a  chance  to  model  the  Augmented  OARS  alternative.  For  this  reason,  the  decision 
matrix  only  illustrates  modeling  MOPs  for  the  CTF-151  solution  and  the  OARS  Basic 
system.  The  OARS  Basic  system  received  a  total  value  score  of  0.96  which  was  almost 
40%  larger  than  CTF-151"s  value  score  of  0.58. 


Measure 

Global  Weight 

Alternatives 

Unopposed 

CTF  151 

OARS  Basic 

UAV Total  Detections 

0.3 

0 

0.7 

1 

UAV  Total 

Classifications 

0,3 

0 

0.2 

1 

UAV  Cumulative 

Launches 

0.1 

0 

0.32 

1 

Blue  Assets  Overtaken 

0.25 

0 

0.93 

1 

Red  Assets  Overtaken 

0.05 

0 

1 

0.34 

Total  Value  Score 

1 

0 

0.58 

0.96 

Figure  38.  Decision  Metrics. 

4.  Cost  Value  Analysis  Conclusions 

Figure  39  below  shows  the  cost  versus  effectiveness  graph  of  the  OARS  Basic 
system  and  CTF-151.  The  graph  shows  that  the  OARS  Basic  system  was  both  more 
effective  and  less  costly  than  CTF-151. 


118 


1.2 


<u  0.8 

W. 

O 

w 

<S) 

Q) 

-2  0.6  - 

03 

> 

a 

-M 

.o 


0.4 


0.2 


0  ♦ 


Cost  vs.  Effectiveness  Graph 


Unopposed 


ICTF151 


Alternative  1: 
OARS  Basic 


5000  10000  15000 

System  Life  Cycle  Cost 


20000 


Figure  39.  Cost  versus  Effectiveness  Comparison. 


5.  Summary 

After  all  analysis  was  complete,  it  was  found  that  the  OARS  Basic  system 
provides  the  most  detections  of  pirates  and  is  the  cheapest  to  operate.  For  these  reasons, 
the  recommendation  is  the  OARS  Basic  system. 


B.  RECOMMENDATIONS 

1.  Recommended  Areas  of  Future  Research 

The  analysis  conducted  by  the  OARS  capstone  team  provided  great  insight  into 
the  effectiveness  of  UAV  technology  in  the  deterrence  of  piracy  within  the  Gulf  of  Aden. 
With  that  being  said,  there  are  still  some  areas  of  further  research  that  can  be  pursued  to 
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provide  a  greater  understanding  of  all  factors  involved  in  anti-piracy  operations.  The 
future  research  categories  are:  modeling  and  analysis,  operational,  and  technical. 


a.  Modeling  and  Analysis 

The  modeling  and  analysis  areas  of  future  research  identify  topics  that  can 
be  further  researched  that  will  provide  greater  insight  into  the  OARS  systenT's 
effectiveness  in  anti-piracy  missions. 

•  Due  to  the  crash  of  the  Naval  Simulation  Software  (NSS),  the  Augmented 
OARS  system  was  not  modeled.  The  benefits  of  adding  a  Broad  Area 
Maritime  Surveillance  (BAMS)  UAV  are  still  unknown,  and  further 
modeling  and  analysis  on  these  benefits  could  provide  insight  into  the 
Augmented  OARS  effectiveness  in  anti-piracy  operations. 

•  Further  research  could  be  conducted  to  help  better  pinpoint  the  average 
force  structure  of  CTF-151  and  in  turn,  a  better  life  cycle  cost  estimation. 
Due  to  the  fluctuation  of  CTF-151"s  force  structure  and  its  unique  use  of 
ships  from  many  countries,  estimating  its"  lifecycle  cost  was  difficult. 

b.  Operational  Areas 

The  operational  areas  of  future  research  focus  on  the  operational  areas 
where  the  OARS  system  may  be  utilized  worldwide.  These  potential  research  topics  will 
provide  more  insight  into  the  OARS  systenf's  ability  to  be  used  to  fight  piracy 
worldwide. 

•  Additional  operational  areas  of  anti-piracy  operations  need  to  be  analyzed. 
The  OARS  team  focused  on  deterring  piracy  within  the  Gulf  of  Aden, 
which  provides  a  unique,  narrow  corridor  of  operation.  However,  Somali 
piracy  has  been  expanding  into  the  Indian  Ocean  and  therefore,  use  of  the 
OARS  systems  in  a  more  open  ocean  environment  should  be  examined. 

c.  Technical  Areas 

The  technical  areas  of  future  research  mostly  define  subsystems  of  the 
OARS  systems  that  require  more  research  to  define  their  validity  in  anti-piracy  missions. 

•  Evaluation  of  the  MQ-8B  Fire  Scout  Vertical  Takeoff  Unmanned  Aerial 
Vehicle  (VTUAV)  as  a  replacement  to  the  SH-60  Helicopter  for  anti¬ 
piracy  missions.  The  OARS  team  ruled  out  the  use  of  the  Fire  Scout  due 
to  the  fact  that  it  did  not  aid  in  the  detention  and  capture  of  pirates, 
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however,  the  Fire  Scout  is  significantly  less  costly  to  operate  and  deserves 
further  research  into  its  use  in  anti-piracy  operations. 

•  Further  research  needs  to  be  conducted  on  the  host  vessef's  ability  to 
intercept  and  monitor  the  pirates"  handheld  satellite  communications  and 
Global  Positioning  Systems  (GPS).  The  pirate"s  use  of  technology  was 
limited,  but  the  ability  of  the  commander  to  monitor  this  information 
would  be  a  crucial  asset  to  anti-piracy  operations. 
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APPENDIX  A  STAKEHOLDER  COMMENTS 


Captain  Brown 

•  CO  of  CG-64  Captured  38  suspected  pirates  and  one  mothership 

•  UAVs  should  not  have  lethal  force 

•  Host  vessel  should  maintain  a  chain  of  evidence  (i.e.  video  record  of 
suspected  pirates  dumping  their  weapons  overboard)  for  the  detention  and 
prosecution  of  pirates. 

LT  Cook 

•  UAVs  should  not  have  lethal  force 

•  Evidence  collection  necessary  and  demanding 

•  Identification  of  pirates  was  very  important  and  made  the  boarding  party 
much  safer 

Captain  Place  (ret  USN) 

•  UAVs  need  high  grade  JP  fuel 

•  IRIDIUM  use  for  Command  and  Control 

•  AIS  Automatic  Identification  System 

•  LCS  radars  are  good  for  tracking 

•  Deploy  EO  IR  Systems  for  ID 

•  ScanEagle  80  nm  range  EO  IR  capability 

•  Fire  Scout  is  modular  and  helpful 

•  BAMS  goes  to  $120M 

•  ScanEagle  with  6  birds  is  $5M  by  INSITU 
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APPENDIX  B  FUNCTIONAL  FLOW  BLOCK  DIAGRAM  (FFBD) 
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Figure  40.  FFBD  1.2,  „Underway  Replenishment" 
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Figure  41.  FFBD  2.1,  „Detectff 
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Figure  42.  FFBD  2.1,  „Fix/Classify" 
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Figure  43.  FFBD  2.3, , Assess  Risk" 
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Figure  44.  FFBD  2.4,  „Tiack" 
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Figure  45.  FFBD  3.1, , Communicate  Internally  -  Fleet  Command" 
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Figure  46.  FFBD  3.2,  Communicate  Internally  -  OARS  Fleet  Command  &  Control" 
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Figure  47.  FFBD  4.1  „Inta*cept" 


4.1 

Intercept 
Combat  Sensor 


4,2,1 


Escort  Threat 


Boarding  Tea... 


I 

1 


Figure  48.  FFBD  4.2,  Neutralize" 
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APPENDIX  C  MODELING  SCENARIO  NUMBERS 


#ofShq» 

CTF 151 

AllCTFs 

Merdiant  Ships  per  1.1  million  mi2 

500/Dav 

US  Naval  Vessels 

3 

17 

Coal  rtion  Vessels 

10 

Pirate  Skiffs 

20/bay 

Pirate  Motherships 

3/Day 

Prate  Or^gm/Base 

Coordinates 

Lat 

7N 58*39.5" 

Long 

49649*22.8" 

Prate  As 

a— mriZfliK/rA  ■■ 

Skiff  Speed  (max) 

40  knots 

Skiff  Enduanoe  (2  Fuel  Cans) 

15  Gallons 

Skiff  Range  (from  Mothership] 

23  mi 

Mothership  Speed  (max) 

lQ/9ave  knots 

Mothership  Endmnoe 

4950  Gallons 

Mothership  Range  (max) 

4000  mi 

Pntc  PiuLdbCty  AmihiImb 

Dctance 

3 

1 

5  miles 

0125 

4  miles 

0.35 

3  miles 

0.45 

2  miles 

0L6 

lmile 

0.75 

.5  mile 

OLS 

.25  mile 

0.9 

.1  mile 

0195 
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Under  CTF 

Alternative  1  -  CTF  151 

Naval  Vessek 

Class  of  vessel 

3 
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DDG  51  Class 
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1  (rotating 

y 

FPG  Class 

Perry 

2 

y 

LPD 17  Class 

San  Antonio 

1  (rotating 

Coa&taon  Vesseb 

10 

n 

Oiinese  Frigate 

Jianwei 

2 

y 

Korean  Frigate 

ULSAN 

1 

y 
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SH60B  Sea  Hawk 

Barbaras 

3 

y 

Sigpapore  Destroyer* 

SH6QJ  SeaHawk 

Foimidable/La  Fayette  Corvette 
dass  frigate 

2 

y 

Canadian  Destoryer* 
SH3D  Sea  King  UAV 

FMGS  Regina/Algonquin 
Frigate/lroquois/Tribal/Hal  ifax 
Frigate 

1 

y 

Frendi  Frigate  t 

Z9C  Dat^ihin  UAV 

Floreal 

1 

Boantmg  HHIB  Boatsf none  m  model) 

28 

y 

DDG  51  Class 

2 

y 

FFG  Class 

4 

y 

LPD  17 

2 

n 

Oiinese  Frigate 

4 

y 

Korean  Frigate 

2 

y 

Tiikey  Frigate 

6 

y 

Signapore  Destroyer 

4 

y 

Canadian  Destoryer 

2 

y 

Frendi  Frigate 

2 
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Alternative  2  -  LCS  1 

Alternative  3  -  Air  M 

Naval  Vessels 

3 

Naval  Airships 

1 

LCS  Class 

1 

MDL-1D0DC1  Dynalifter 

1 

DDG  51  Class 

1 

Naval  Vessels 

2 

LPD  17 Class 

1 

DDG  51  Class 

1 

LPD  17 Class 

1 

Coalition  Vessefc 

IQ 

Chinese  Frigate 

2 

CoaStion  Vessels 

16 

Korean  Frigate 

1 

Chinese  Frigate 

2 

Tirkey  Frigate 

3 

Korean  Frigate 

1 

Signapore  Destroyer 

2 

Tirkey  Frigate 

3 

Canadan  Destoryer 

1 

Signapore  Destroyer 

2 

French  Frigate 
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Canadan  Destoryer 

1 

French  Frigate 

1 

Boardina  RHtB  Boats 

IB 

DDG  SI  Class 

2 

Boardina  td-ttB  Boats 

16 

LCS  Class 

2 

DDG  51  Class 

2 

LPD  17 

2 

LPD  17 

2 

Chinese  Frigate 

2 

Chinese  Frigate 

2 

Korean  Frigate 

2 

Korean  Frigate 

2 

Tirkey  Frigate 

2 

Tirkey  Frigate 

2 

Signapore  Destroyer 

2 

Signapore  Destroyer 

2 

Canadan  Destoryer 

2 

Canadan  Destoryer 

2 

French  Frigate 

2 

French  Frigate 

2 

l/AV-Optionl 

16 

UAV-Qpdwnl 

? 

Scan  Eagle  (LCS) 

9 

Scan  Eagle  (Dynalifter 

2 

Scan  Eagle  (DDG) 

3 

Scan  Eagle  (DDG) 

3 

Scan  Eagle  (LPD) 

4 

Scan  Eagle  (LPD) 

4 

UAV-QptiDn2 

3 

UAV  Option  2 

z 

UAV2(LCS) 

4 

UAV  2  (Dynalifter) 

2 

UAV  2  (DDG) 

2 

UAV  2  (DDG) 

2 

UAV  2(LPD) 

3 

UAV  2(LPD) 

3 

UAVOptmtl 

? 

UAVOptktnJ 

z 

UAV  3  (LCS) 

4 

UAV  3  (Dynalifter) 

2 

UAV  3  (DDG) 

2 

UAV  3  (DDG) 

2 

UAV  3  (LPD) 

3 

UAV  3  (LPD) 

3 

Land  Bases. 

1 

Land Bases 

1 

5th  Fleet  HQ-  Bahrain 

1 

5th  Fleet  HQ-  Bahrain 

1 

Refuetina  Bases. 

2 

RefaeUna  Bases 

2 

□idkai 

1 

DrAkai 

1 

Quatar 

1 

Quatar 

1 
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APPENDIX  D  RISK  MANAGEMENT 


A.  RISK  MANAGEMENT  STRATEGY 

Risk  can  be  defined  as  .  .the  net  negative  impact  of  the  exercise  of  vulnerability, 
considering  both  the  probability  and  the  impact  of  occurrence”  (NIST,  1).  Risk 
management  is  a  continuous  process  that  is  accomplished  throughout  the  life  cycle  of  a 
system.  It  is  a  process  that  encompasses  risk  identification,  analysis,  assessment, 
mitigation  planning,  mitigation  implementation,  monitoring,  and  tracking.  Early 
identification  of  the  OARS  project  risks  allowed  for  early  implementation  of  mitigation 
strategies  and  therefore  improved  the  likelihood  of  the  project  achieving  its  stated 
objectives.  Risks  were  identified  during  project  analysis,  established  and  reviewed  with 
primary  stakeholders,  and  continuously  monitored  and  managed  throughout  the  OARS 
project' 's  lifecycle.  Risks  were  managed  by  order  of  criticality  and  the  data  obtained  was 
documented.  The  risk  management  IPT  created  a  risk  management  strategy  that 
illustrated  the  process  in  which  the  OARS  team  used  to  mitigate  risks. 

A  risk  mitigation  strategy  was  developed  to  assist  in  the  mitigation  process  in 
order  to  determine  whether  or  not  an  improvement  was  acceptable.  The  strategy  defined 
how  risks  were  managed  throughout  the  lifecycle  of  the  project.  For  this  strategy,  there 
were  three  stages.  These  stages  were: 

1)  Risk  Assessment. 

2)  Risk  Control. 

3)  Risk  Review. 

Proper  processes  were  instilled  in  the  OARS"  risk  management  effort  to  ensure 
that  sufficient  communication  of  risk  information  was  provided  to  all  involved.  Model  1 
below  displays  the  OARS  Teanf'sRisk  Management  Strategy  along  with  the  three  stages 
involved.  The  OARS  risk  management  process  was  initiated  and  used  to  assess,  mitigate 
and  review  the  risks.  If  in  the  control  stage,  the  risk  is  unacceptable,  it  returned  to  the 
assessment  stage  for  reevaluation  and/or  removal.  If  the  risk  is  accepted,  it  moved 
forward  through  documentation  and  review.  During  the  review,  if  a  risk  was  discovered 
that  was  not  previously  anticipated,  the  risk  was  passed  backwards  to  the  Risk  Control 
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stage  and  if  necessary,  back  to  the  Risk  Assessment  stage.  Each  stage  of  the  risk 
management  process  will  be  discussed,  beginning  with  Risk  Assessment. 

Risks  were  managed  by  order  of  criticality  and  the  data  obtained  was 
documented.  There  were  three  areas  of  importance  in  the  OARS  teanf's  risks.  The  areas 
of  importance  were  as  follows:  Technical  Risk,  Model  Risks,  and  Project  Risk.  Once  the 
risks  were  established,  a  Risk  Prioritization  Matrix  was  then  developed.  Below  is  a 
breakdown  of  the  biggest  risks  that  were  identified  during  the  project,  as  well  as  their 
mitigation  strategies. 


Figure  49.  Risk  Management  Process. 

1.  Stage  1  Risk  Assessment 

Risk  assessment  is  the  identification,  analysis,  and  evaluation  of  the  levels  of  risks 
involved  in  a  situation  as  shown  in  Model  2  below.  It  is  the  first  stage  of  the  risk 
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management  process  that  will  determine  whether  or  not  there  is  an  acceptable  level  of 
risk  for  the  OARS  system. 


Figure  50.  Stage  1,  Risk  Assessment. 
a.  Risk  Identification 

Risk  identification  is  the  activity  that  examines  each  element  of  the  project  to 
identify  associated  cause,  begin  documentation,  and  set  the  stage  for  the  successful 
OARS  risk  management  process.  To  identify  any  risks  of  the  OARS  project,  the  “what 
can  go  wrong”  questions  were  asked.  To  answer  the  questions,  “IF  -  THEN”  statements 
were  formed.  A  condition- to-consequence  risk  statement  was  generated.  For  example, 
IF  Coalition  forces  do  not  acquire  pirate  identification  in  time,  THEN  the  probability  of 
pirate  boarding  increases.  A  table  containing  the  top  eight  risks  was  developed  using  this 
method  and  is  shown  below.  The  risk  number  values  were  taken  from  the  Risk  Reporting 
Matrix  (RRM),  located  in  Section  1.1. 1.2.  Once  the  risks  were  identified,  the  next  step  in 
the  process  was  to  complete  a  risk  analysis  of  the  system. 
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Table  25.  Identified  Risks  with  Partial  Mitigation. 


F - 

No. 

RISK 

Impact 

Likelihood 

Risk  Type 

M;i  mt  gt/ft  lit  ig  a  t  e 

i 

IF  OARS  cannot  complete  the  M&S  activity, 
THEN  system  will  lack  data  for  consideration 
of  alternatives 

c 

90°  o 

Model 

Overcome  technical  NSS 
difficulties  with  SMI  Metron 

2 

IF  Coalition  forces  ilo  not  acquire  pii  ate 
identification  In  Untie,  THEN  Hie  probability  of 
pi  i  ale  hoardin'*  inf  lenses 

c 

30°  ft 

Mission 

Have  capability  to  sense  targets 
of interest 

3 

IF  Differential  GPS  mounted  on  UAV  or 
Skyhook  Is  damaged  w  hile  in  operation.  THEN 
recovery  of  UAV  would  he  difficult 

s 

20°  ft 

Technical 

Use  alternative  method  to 
recover  UAV  (Net) 

4 

IFOARS  system  to  system  integration  has 
incompatibility  problems  THEN  a  raitiu  e  could 
occur  causing  loss  of  craft, 

Mo 

40°  a 

Technical 

Select  a  proven 
software  hat  dw  ai  e  package 

5 

IF  Coalition  Stave  proprietary  issues  with 
technology.  THEN  the  objectives  for  the  effort 
will  not  be  fulfilled 

Ml 

5°to 

Mission 

Build  equipment  using 
International  standards  (ISO) 
for  quality  and  manufacturing 

6 

IF  Coalition  lacks  ability  to  adapt  to  change  In 
pirate  tactics  and  weapons.  THEN  increased 
loss  of  assets  w  ill  occur. 

C 

3U°ft 

Operational 

Acquire  FOUO  Intel  on  pirate 
tactics  and  weapon  acquisition 
to  monitor  pirate  activity 

7 

IF  Multiple  attacks  to  several  commercial  ships 
occur  at  the  same  time.  THEN  there  could  be  a 
loss  of  situation  awareness  and  safety  to 

Civilian  vessels  Is  compromised 

C 

50°ft 

Technical 

Review  technical  specifications 
that  has  contingency  for  swarm 
effect 

B 

IF  new  capabilities  and  requirements  ate 

added  (n  Hie  OARS  system.  THEN  more  testing 
will  he  required,  causing  possible  delay  in 
pi  oj  ecteo  millet  1  u  n 

S 

20°  ft 

Technical 

Cost 

I  n  v  t  A  v  e  s  t  a  k  eh  oh  1  els  1  la  fit  t  u  i  e 
planning  for  Intel,  Delay  code 
freeze  until  latest  possible  time 

9 

IF  OARS  cannot  be  fully  supported  by 
necessary  manpower  due  to  Injury,  THEN  the 
ability  to  operate  OARS  efficiency  will  be  an 
issue 

s 

10°  to 

Personnel 

Use  of  IMPRINT  and 
Involvement  of  HSI  early  In  the 
development  process, 
IMPRJNT-N  for  Navv 

HI 

IF  there  Is  limited  capability  for  scenarios  in 
M&S,  THEN  Hie  ability  to  see  full  measure  of 
OARS  capability  will  be  limited  as  well. 

Mo 

30°  # 

Model 

— 

Accept  risk 

» 

IF  OAKS  Jack  stakeholder  requirements, 

THEN  1  lie  actual  recommended  solution  may 
not  correctly  address  the  need 

IV  □ 

IO°  o 

Project 

Retrieve  sufficient  stakeholder 
in  pul  in  Hie  requli  eiueiil 
solid  la  lion  process 

12 

IF  deployment  schedule  Is  to  stringent.  THEN 
OARS  system  may  not  be  mission  capable 

Mo 

20°o 

Project 

Reoijent  schedule  to  follow 

Inci  emeu  lal  deployment 

13 

IF  budget  cannot  allocate  fa  lilting  to  OARS 
system  by  procurement  date.  THEN  system 
cannot  bp  implemented 

S 

50°o 

Project 

Acquire  proper  all  procurement 
and  operations  support 

Mi  =  Minor  Mo  =■ 

Moderate 

S  —  Serious 

C  —  Ciilicai 

b.  Risk  Analysis 

Risk  analysis  involves  identifying  the  most  probable  risks  to  the  project  and 
analyzing  the  related  vulnerabilities  to  these  risks.  The  intent  of  risk  analysis  was  to 
answer  the  question  “How  big  is  the  risk?”  This  is  accomplished  by: 

•  Considering  the  likelihood  of  the  risk  occurrence, 

•  Identifying  the  possible  consequences/impact  for  this  project  in  terms  of 
schedule,  and 
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•  Identifying  the  risk  level  using  the  Risk  Reporting  Matrix  shown  in  Figure 
51  below. 

A  Quantitative  risk  assessment  requires  calculations  of  two  components  of  risk: 
the  consequence/impact  of  the  potential  loss,  and  the  probability  that  the  loss  will  occur. 
The  OARS  team  defined  the  criteria  for  likelihood  and  consequence  or  impact  for 
evaluating  the  project' 's  risk.  The  use  of  the  Risk  Reporting  Matrix  below  displayed  the 
level  of  the  risks  identified  within  the  project.  The  level  of  risk  was  then  documented 
with  a  consequence/impact  ranging  from  negligible  to  critical.  In  Figure  1,  the  level  of 
likelihood  of  each  risk  was  established  using  specified  criteria.  The  level  of  likelihood 
for  the  OARS  project  ranges  from  “remote”  to  “near  certainty.”  For  example,  if  the  risk 
has  an  estimated  50  percent  probability  of  occurring,  the  corresponding  likelihood  is 
“likely.” 


Technical  Risks 

L  Modeling  &  simulation 
2«  Target  identification  failure 
Launch  &  recovery 
4.  System  integration 

S«  Interoperability  of  system  ami  coalition 
6.  Change  in  pirate  tactics  and  weapons 
1,  Pace  of  operation 

8.  Adding  new  capability  and  requirements 
9*  Manning 

10. Limited  scenario  capability 
1  l.Laek  of  stakeholder  requirements 
1 2. Deployment  schedule 
13*Cost  projection 


CffUmty 
<*1  100N) 


Highly  Likely 
(C140H) 

T3 

O 

O  l.kHy 
-C  (4 1  60S) 


Unlikely 

111-40*) 


Rrmotr 

(0-10*) 


Consequence/Impact 


Figure  51.  OARS  Risk  Matrix. 

To  analyze  the  risks  even  further,  the  OARS  team  also  used  fault  trees  to  illustrate 
the  undesired  state  of  the  system.  The  use  of  fault  trees  assisted  with  the  determination  of 
system  functional  failure  probability. 
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c.  Fault  tree  analysis  (FTA) 

The  fault  tree  was  one  of  the  methodologies  used  for  each  of  the  OARS  risks.  It 
helped  to  determine  whether  or  not  the  risk  was  acceptable.  This  tool  assumes  failure  of 
the  functionality  of  a  product  or  process  (Kirupakar  2011).  The  results  were  represented 
pictorially  in  the  form  of  a  tree  of  fault  modes.  This  was  used  to  investigate  complaints 
or  deviations,  and  allowed  the  team  to  fully  understand  their  root  cause  and  ensure  that 
intended  improvement  would  resolve  the  issues  and  not  cause  any  other  problems 
(Kirupakar  2011).  A  good  example  of  this  tool  is  provided  below  in  figure  3. 


Figure  52.  Fault  Tree  Analysis  of  Identification  Failure  Risk. 


Figure  3  shows  a  representation  of  a  fault  tree  for  the  first  technical  risk  of  the 
OARS  system.  This  tree  introduces  complex  units  known  as  “gates,”  which  serve  to 
allow  or  hinder  the  passage  of  fault  logic  up  the  tree.  The  gates  show  the  relationships  of 
events  that  are  needed  “higher”  events  to  occur  (Vesely  1981).  In  this  case, 

“Identification  failure”  is  the  higher  event,  which  is  the  output  of  the  „and"  gate.  The 
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lower  events  are  the  inputs  to  the  „and"  gate.  The  „AND"  gate  is  used  when  the  output 
occurs  if  all  the  inputs  are  true.  The  „OR"  gate  is  used  when  the  output  occurs  if  at  least 
one  of  the  inputs  are  true.  The  „basic  event"  symbol  is  used  when  initiating  a  fault 
requiring  no  further  development. 

d.  Risk  Evaluation 

Risk  evaluation  is  the  process  of  analyzing  potential  losses  from  a  given  risk 
using  a  combination  of  known  information  about  the  situation,  knowledge  about  the 
underlying  process,  and  judgment  about  the  information  that  is  not  known  or  well 
understood.  The  OARS  team  was  assigned  to  each  identified  risk,  with  priority  given  to 
the  most  critical  risks  first.  The  OARS  teanf's  risk  evaluation  involved  assessing  existing 
controls  and  their  adequacy  relative  to  the  potential  threats. 

2.  Stage  2  Risk  Control 


a.  Risk  Mitigation  Plan 

The  objective  of  the  OARS  risk  mitigation  efforts  was  to  lower  the  probability  of 
the  risk  event  occurrence,  and  to  explore  risk  response  strategies  for  the  high  risk  items 
identified  in  the  qualitative  and  quantitative  risk  analysis.  The  process  identified  and 
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assigned  OARS  IPTs  to  take  responsibility  for  each  risk  response.  It  ensured  that  each 
risk  requiring  a  response  had  an  owner.  The  intent  of  risk  mitigation  planning  was  to 
answer  the  following  question:  “What  is  the  program  approach  for  addressing  this 
potential  unfavorable  consequence?”  One  or  more  of  the  following  mitigation  options 
may  have  applied: 

1 .  Avoid  risk  by  eliminating  the  consequence/impact, 

2.  Control  the  likelihood  and  consequence/impact, 

3 .  T ransfer  the  risk, 

4.  Accept  the  level  of  risk  and  continuing  on  the  current  project  plan. 

Table  26  represents  some  of  the  tools  and  techniques  that  the  OARS  team  used  to 
assist  in  reducing  the  likelihood  of  the  risks  occurring. 


Table  26.  Risk  Tools.  (From  Engineering  Risk  Benefit  Analysis.  DoD  Risk 
Management  V03-25-201). 


PERSONNEL 

PROCESS 

TECHNOLOGY 

TRAINING 

DEFINE  REQUIREMENTS 

USE  PROVEN  TECHNOLOGY 

HIRING/PROM  Oil  ON 

DESIGN  REVIEWS 

MOCK-UPS  &  PROTOTYPING 

COMMUNICATION 

RIGOR 

TECHNOLOGY  MATURATION 

LEADERSHIP 

TEST  PROGRAM 

REDUNDANT  DESIGN 

KNOWLEDGE  SHARING 

TRADE  STUDIES 

ROBUST  DESIGN 

MODELING  & 

OPEN  SYSTEMS 

SIMULATION 

b.  Risk  Mitigation  Implementation 

After  the  risks  had  been  analyzed  and  documented  according  to  their  levels  of 
priority  in  the  mitigation  plan,  the  development  and  integration  of  the  corresponding  risk 
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mitigation  strategies  followed  and  were  referenced  against  the  previously  prepared  risk 
management  plan. 

c.  Risk  Acceptance 

The  concept  of  risk  acceptance  asked  the  question,  “How  safe  is  safe  enough?” 
The  OARS  team  collaborated  with  its  stakeholders  in  determining  the  acceptable  level 
with  which  some  risks  within  the  project  would  be  allowed. 

2.  Stage  3  Risk  Review 


t 

/HBT\ 


Figure  54.  Stage  3  Risk  Review. 
a.  Risk  Monitoring  and  Tracking 

Risk  monitoring  and  tracking  “is  the  process  for  tracking  identified  risks, 
monitoring  residual  risks,  identifying  new  risks,  executing  risk  response  plans,  and 
evaluating  their  effectiveness  throughout  the  project  life  cycle"  (Project  Management 
Institute  2008,  237). 

The  OARS  risks  were  regularly  monitored  and  tracked  through  the  lifecycle  of  the 
project.  The  OARS  team  monitored  and  tracked  the  risks  in  intervals  of  weekly 
meetings.  The  meetings  addressed  the  implementation  of  risk  handling  actions  and  their 
impact  to  the  project.  The  OARS  team  monitored  risk  mitigation  plans  and  their 
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progress,  reviewed  and  updated  risk  status,  and  communicated  the  risks  to  all  affected 
stakeholders.  The  status  of  each  risk  was  displayed  on  the  Risk  Reporting  Matrix 
discussed  earlier  in  this  document.  The  OARS  team  communicated  any  changes  in  the 
risks  and  mitigation  plan  with  the  appropriate  personnel. 

B.  OARS  RISK  ANALYSIS 

Risks  were  managed  by  order  of  criticality  and  the  data  obtained  was 
documented.  There  were  three  areas  of  importance  in  the  OARS  teanT's  risks.  The  risks 
were  as  follows:  1.  Technical  Risk,  2.  Model  Risks,  and  3.  Project  Risk.  Once  the  risks 
were  established,  then  a  Risk  Prioritization  Matrix  was  developed. 

1.  Technical  Risks 

Risk  #7:  Pace  of  Operation.  The  inability  of  OARS  to  handle  simultaneous  attacks 
would  cause  loss  of  situational  awareness.  Mitigation  Strategy:  Review  technical 
specifications  which  have  a  contingency  plan  for  swarm  effect  and  implement  when 
necessary. 

Risk  #6:  Change  in  Pirate  Tactics  (OARS  inability  to  adapt  to  the  change  in 
opponent  tactics  resulting  in  mission  failure).  Mitigation  Strategy:  Acquire  “For  Official 
Use  Only”  (FOUO)  intelligence  on  pirate  tactics  and  weapon  acquisitions  to  monitor 
pirate  activity  in  real  time. 

Risk  #2:  Target  Identification  Failures.  This  had  a  large  potential  for  OARS  to  be 
unable  to  detect/identify  pirates  in  a  timely  manner  causing  mission  failure.  Mitigation 
Strategy:  Utilize  proven  capability  to  sense  targets  of  interest  with  backup  contingencies. 

2.  Model  Risks 

Risk  #1 :  The  M&S  team  was  new  to  the  NS  S  modeling  &  simulation  program  and 
had  very  little  experience,  requiring  oversight  from  knowledgeable  associates.  Hence, 
actual  model  results  may  not  be  accurate,  resulting  in  an  improperly  recommended 
solution.  Mitigation  Strategy:  The  team  attempted  to  mitigate  this  problem  by 
proactively  meeting  2-5  times  a  week  to  facilitate  rapid  learning  and  model  construction. 
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Risk  #10:  NSS  Software  Limitations.  The  OARS  NSS  model  was  very  limited  in 
contrast  to  what  scenarios  the  M&S  team  wanted  to  simulate.  The  objective  was  to 
model  the  entire  Indian  Ocean,  but  only  the  Gulf  of  Aden  was  modeled  because  of  time 
restrictions  and  program  capabilities.  Mitigation  Strategy:  Accept  the  Risk. 

3.  Project  Risks 

Risk  #8:  Requirements/Capability  Change.  This  could  change  the  scope, 
requirements,  and  capabilities  incurring  delays  and  increased  development  cost. 
Mitigation  Strategy:  Involve  stakeholders  in  future  planning  for  intelligence  and  delay 
code  freeze  until  latest  possible  time 

Risk  #11:  Lack  of  stakeholder  requirements.  The  OARS  project  had  few 
participating  stakeholders.  Stakeholder  feedback  was  very  limited.  Hence,  the 
recommended  solution  may  not  correctly  address  the  actual  needs  and  requirements  of 
the  stakeholders.  Mitigation  Strategy:  To  reduce  this  risk,  the  Stakeholder  IPT  made 
many  attempts  to  retrieve  stakeholder  feedback  in  the  requirements  solicitation  process. 
It  is  recommended  that  any  future  development  of  this  proposal  re-solicit  stakeholders  for 
further  feedback. 

Risk  #12:  Deployment  schedule.  The  OARS  project  has  a  projected  deployment 
date  of  2020.  Because  of  this  tight  deployment  schedule,  OARS  may  not  be  mission 
capable  by  this  date,  thus  failing  to  meet  the  needs  of  the  stakeholders.  Mitigation 
Strategy:  Re-orient  the  deployment  schedule  to  follow  an  incremental  deployment 
schedule.  Hence,  incorporate  additional  UAVS  and  increase  capabilities  as  successful 
fielding  occurs. 

Risk  #13:  Cost  projection.  Due  to  a  decrease  in  weapon  system  budget  allocation, 
obtaining  the  expected  costs  for  the  OARS  system  may  be  at  risk  through  2016,  which  is 
the  projected  congressional  authorization.  Mitigation  Strategy:  Acquire  proper  Ally 
procurement  and  operations  support. 
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4.  Risk  Prioritization  Matrix 

Now  that  the  three  categories  of  risks  have  been  established,  a  prioritization 
matrix  of  those  categories  was  developed  in  order  to  show  the  overall  status  of  the  risks 
of  the  OARS  system. 


Overall  Risks 

I  -  Technical  Risks 
2*  Model  Risks 
3,  Project  Risks 


T3 

Q 

O 


hM/Cprtjiintj 


Highly  L.fc*ly 
(il 


□  nil  My 

[ti 


nKtni 


Nr^Jl'p-blf  Ulntt  ModFrlfo  Sfi'OUl  C  r  ■  ll£ji 


C  onsequenceilmpact 


Figure  55.  OARS  Risk  Matrix. 
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Risk  #  1-ModeJing  and  Simulation 


Risk  Owner:  OARS  Category:  90%  -  C 

Description:  M&S  completion  with  satisfactory  scenario  data 
collection,  analysis,  and  Capstone  insertion 


Mitigation  Steps: 

1,  Overcome  technical  NS5  difficulties  with  SME  Matron. 

2.  Complete  M&S  CTF  data  run  and  collect  data  quickly 

3,  a.  Complete  M&S  alternate  software  application  attempt 
b.  Complete  Data  Analysis  with  retrieved  Data 

4.  If  alternative  M&S  successfully  runs,  complete  data 
analysis  to  be  inserted  In  the  Capstone  project. 


Mi  =  Minor  Mo  =  Moderate  S  =  Senous  C  =  On  heal 

Figure  56.  Risk  #1:  Modeling  and  Simulation. 


Risk#  2-Target  Identification  Failure 


Risk  Owner;  OARS 

Description:  For  the  identification  of  a  target,  the  radars, 
themselves,  must  be  capable  of  very  accurately  determining  the 
positions  of  the  targets. 


Mitigation  Steps: 

1.  Have  capability  to  sense  targets  of  interest 
2*  Assume  risk  with  procedures  that  dictate  visual 
identification 


Category:  30%  -  C 


Mi  -  Minor  Mo  =  Moderate  S  =  Senous  C  =  Critical 


Figure  57.  Risk  #2:  Target  Identification  Failure. 
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Risk#  6-Change  in  pirate  tactics  and  weapons 


Risk  Owner:  OARS 

Description:  Have  the  capability  to  adapt  to  change  in  pirates 
tactics  and  weapons  fn  real  time 

Mitigation  Steps: 

1.  Acquire  real  time  FQUO  Intel  on  pirate  tactics  and 
weapon  acquisition  and  activity* 

2.  System  respond  to  an  attack  prior  to  boarding. 

3.  Encrypt  codes  in  radio  communication  for  security 

4.  Use  of  MATO  and  US  platforms  to  cover  larger  areas 
during  patrols 

5.  24/7  Surveillance 


Category:  30%  -  C 


CVPTWqWIKt 


Mi  =  Minor  Mo  =  Moderate  S  =  Serious  C  =  Critical 


Figure  58.  Risk  #6:  Change  in  Pirate  Tactics  and  Weapons. 


Risk#  7-Pace  of  Operation 

Risk  Owner:  OARS  Category:  50%  -  C 

Description:  Must  maintain  situation  awareness  during 
multipie  attacks  to  several  commercial  ships  occurring 
at  the  same  time. 


Mitigation  Steps: 

1.  Review  technical  specifications  that  has  contingency 
for  swarm  effect 

2 *  Training  of  anti-pirate  personnel. 

3„  24/7  Surveillance 

4-  Stagger  patrol  during  calmer  weather 


Mi  =  Minor  Mo  =  Moderate  S  =  Serious  C  -  Cntical 


Figure  59.  Risk  #7:  Pace  of  Operation. 
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APPENDIX  E  HOST  SHIP  COST  COMPARISON 


As  discussed  in  Chapter  II,  Problem  Definition,  the  Concept  of  Operations 
(CONOPS)  of  the  OARS  system  includes  coverage  of  1.1  million  square  miles  of  ocean. 
In  order  to  accomplish  this  feat,  six  host  ships  will  need  to  be  utilized.  The  OARS 
system"s  requirement  for  six  host  ships  can  be  fulfilled  by  the  use  of  many  different  naval 
vessels,  including:  LPD,  LHA,  LCC,  CG,  DDG,  and  FFG  ships.  However,  the  limited 
number  of  LPDs,  LHAs,  and  LCCs  in  the  U.S.  Naval  Fleet  precludes  the  use  of  more 
than  one  of  these  capital  ships  in  the  Gulf  of  Aden  OARS  system.  A  procurement  cost 
comparison  to  this  six-ship  system  in  the  Gulf  of  Aden  is  presented  in  both  Table  27  and 
Figure  60. 


Table  27.  Host  Ship  Combination  Count  for  each  Alternative. 


CoTOtoo  » 

LCS 

LPD 

LHA 

LCC 

CG 

DDG 

FFG 

- 

S 

2 

- 

* 

* 

* 

3 

l 

4 

l 

y 

y 

5 

* 

A 

i 

$ 

1 

4 

4 

7 

4 

3 

S 

- 

- 

y 

3 

3 

f 

A 

5 

10 

1 

1 

■* 

ii 

4 

4 

3 

1 

12 

4 

2 

13 

* 

1 

1 

9 
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Procurement  Cost  in  Millions  of  US  Dollars 

M  t*  Qi  rn  O  M  1- 

3  ft  §  8  3  8  8 

00600000 

1 

1 

12345  6789  10  11  1213 

OARS  Host  ship  combination  Cost  Reference  # 

Figure  60.  Costs  of  Alternatives  to  Host  Ship  Procurement. 

Figure  60  shows  that  the  procurement  cost  of  Combination  1,  which  consists  of 
six  Littoral  Combat  Ships  (LCS),  is  the  least  costly  solution.  For  this  reason,  the  OARS 
team  utilized  six  LCS  vessels  in  both  of  the  OARS  alternatives. 
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APPENDIX  F  TABLES  USED  IN  COST  ANALYSIS 


Table  28.  Functional  Objective  Area  of  Interest  for  OARS  Sub-Systems. 


Item 

Quantity 

Detection 

C-3 

L&T 

Engage 

LCSShip 

6 

X 

X 

X 

UAV's 

9/12*6 

X 

SH-60 

12 

X 

X 

X 

X 

RHIB 

12 

X 

X 

50  Cal  MG 

12 

X 

BAMS 

2 

X 

X 

X 

Table  29.  2010  Inflation  Rates  from  a  NAVAIR  Procurement,  (taken  from 
NCCA  Inflation  Indices  2010) 

APN  *  Aircraft  Procurement.  Navy  (1506) 


Base  Year  =  2010  2/24/2009 


Fiscal 

Year 

Inflation 
Rate  % 

Raw 

Index 

Weighte 
d  Index 

Budget 

Year 

Index 

Budget 
Year 
Inflation 
Rate  % 

1996 

2  00% 

0  7901 

0  8078 

0  7890 

1  40% 

1997 

1  80% 

0  8043 

0  8148 

0  7957 

0  86% 

1998 

0  70% 

0  8100 

0  8242 

0  8050 

1  16% 

1999 

0  80% 

0  8164 

0  8348 

0  8153 

1  28% 

2000 

1  40% 

0  8279 

0  8459 

0  8261 

1  33% 

2001 

1  80% 

0  8428 

0  8560 

0  8360 

1  19% 

2002 

0  80% 

0  8495 

0  8668 

0  8466 

1  26% 

2003 

1  00% 

0  8580 

0  8841 

0  8635 

2  00% 

2004 

2  00% 

0  8752 

0  9074 

0  8863 

2  64% 

2005 

2  80% 

0  8997 

0  9330 

0  9112 

2  81% 

2006 

3  10% 

0  9276 

0  9588 

0  9364 

2  77% 

2007 

2  70% 

0  9526 

0  9812 

0  9583 

2  33% 

2008 

2  40% 

0  9755 

0  9959 

0  9726 

1  50% 

2009 

1  50% 

0  9901 

1  0089 

0  9853 

1  31% 

2010 

1  00% 

1  0000 

1.0239 

1  0000 

1  49% 

2011 

1  40% 

1  0140 

1.0413 

1  0170 

1  70% 

2012 

1  70% 

1  0312 

1  0599 

1  0351 

1  78% 

2013 

1  80% 

1  0498 

1  0790 

1  0538 

1  60% 
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Table  30.  Collection  of  Procurement  and  LLCs  by  Reference  Year  (various). 


item 

Acquisition  $M  or  K/ymt 

O&S  $  M  or  K  /  unit 

Quantity 

nfe  cycle 

0&S6  Sys/yr$M 

ICC  6  sys  $M 

fy  Price 

LCS  Shipf 

□SO  M/ship 

43  M 

6 

25  years 

253 

7950 

FY1£> 

(jaws'1-15 

7  M/12 

$3,842  M 

1 

6 

.15  years 

47.304 

793.56 

FY  OS 

SH-60* 

42.417  M/A.C 

23  M/  a/c 

1 

12 

1 

4,5  years 

335 

5549,004 

FY04 

mq-sbt 

16,2  M 

1.97  M 

12 

— * 

10  years 

23.65 

549.2 

FY06 

RHIB5 

ICQfc 

3.65  M/yr 

12 

* 

10  years 

43.8 

65S  2 

FY1X 

50  Cal  M<3J 

14.00k/Gun 

2.Sk/gun 

12 

15  years 

0.0336 

0.504 

FYll 

BAMS* 

220  M 

169,33 

2 

— 1 

15  years 

339.6626667 

2,547.47 

FY1I 

50  Cal  Ammo" 

1.85  K/1,000=L65  Mf  Million 

M/A 

IM 

15  years 

1.35 

L85 

FY  U 

The  above  table  was  used  to  collate  the  data  from  various  element  procurement  and  then  life-cycle  costs  by  reference  year 
(various). 


Table  31.  Costs  Set  to  Base  Year  FY11  from  Procurement  Costs  and  LCCs. 


item 

Acquisition  $  M  or  K/unit 

O&S  S  M  or  K  /  unit 

Quantity 

Lifecycle 

O&S  6  sys/yr  $M 

LCC  6  sys  SM 

FY  Price 

LCS  Ship5 

689.52  M/ship 

43.602  M 

6 

25  years 

261.612 

8004.18 

FYll 

UAV’s“  12 

7.65  M/12 

$4.31  M 

6 

15  years 

51.71 

775.61 

FY  11 

SH-60* 

49.14  M/A.C 

32.44  M/  a/c 

12 

4.5  years 

389.26 

5838.95 

FYll 

MQ-8B* 

17.71  M 

2.15  M 

12 

10  years 

25.85 

600.32 

FYll 

RHIB5 

100K 

3.65  M/  yr 

12 

10  years 

43.8 

658.2 

FYll 

50  Cal  MG5 

14.00k/Gun 

2.8k/gun 

12 

15  years 

0.0336 

0.504 

FYll 

BAMS10 

220  M 

169.83 

2 

15  years 

339.6626667 

2,547.47 

FYll 

50  Cal  Ammo" 

1.85  K/1,000-1.85  M/  Million 

N/A 

1M 

15  years 

1.85 

1.85 

The  above  table  was  used  to  inflate  costs  to  a  base  year  FY  2011  from  various  element  procurement  and  then  life-cycle  costs. 
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Table  32.  Alternative  1  Cost  per  Life  Cycle  Year. 


2016 

2017 

2013 

2019 

2020 

2021 

2022 

2023 

2024 

2025 

2026 

2027 

2023 

2029 

2030 

2031 

2032 

2033 

2034 

2035 

Totals 

Procurement 

£ 

1.000 

$ 

1,970 

$ 

1,000 

i  600 

$  - 

£  - 

£  - 

£  - 

£  - 

5  630 

5  - 

s  - 

s  - 

s  - 

S  720 

s  - 

£  - 

£  - 

£  - 

£  - 

$ 

5,967 

Integration 

£ 

$  300 

$  600 

$  360 

$  140 

£  - 

5  - 

$  - 

s  - 

5  - 

5  - 

s  - 

$  - 

£  - 

£  - 

£  - 

$  - 

$  - 

5  - 

£  - 

$ 

1.400 

Logistics 

$ 

$ 

$ 

$  - 

$  296 

$  297 

$  293 

$  299 

$  300 

$  301 

$  302 

$  303 

$  304 

$  306 

$  303 

$  310 

$  312 

$  313 

$  313 

$  313 

£ 

4rS94 

Operations 

$ 

s 

$ 

i  - 

$  210 

$  211 

$  212 

$  213 

$  214 

$  215 

$  216 

$  217 

$  213 

$  219 

$  220 

$  221 

$  212 

$  120 

$  60 

£  - 

$ 

2,949 

Maintenance 

$ 

$ 

$ 

s  - 

s  - 

£  13 

S  14 

£  15 

$  16 

£  17 

$  13 

$  19 

$  20 

£  21 

$  22 

£  23 

£  24 

$  10 

$  7 

£  - 

£  239 

Disposal 

$ 

$ 

$ 

s  - 

$  - 

$  - 

$  - 

$  - 

$  - 

5  - 

$  - 

5  - 

5  - 

$  - 

$  - 

$  - 

$  - 

s  - 

£  5 

$  10 

$ 

15 

Table  33.  Alternative  2  Cost  per  Life  Cycle  Year. 


2016 

2017 

2013 

2019 

2020 

2021 

2022 

2023 

2024 

2025 

2026 

2027 

2023 

2029 

2030 

2031 

2032 

2033 

2034 

2035 

Totals 

Procurement 

£  930 

$ 

lr7S0 

£ 

750 

S  100 

$  - 

$  - 

$  - 

s  - 

5  - 

£  599 

s  - 

$  - 

s  - 

$  - 

&  324 

£  - 

s  - 

£  - 

s 

- 

5  - 

£ 

5.033 

Integration 

$ 

$  293 

$ 

643 

$  428 

$  138 

$  - 

$  - 

$  - 

5  - 

£  - 

$  - 

$  - 

$  - 

$  - 

£  " 

$  - 

$  - 

5  - 

$ 

- 

$  - 

$ 

1.512 

Logistics 

$ 

$ 

$ 

- 

5  - 

$  335 

$  335 

$  336 

$  337 

$  333 

$  339 

$  390 

$  391 

$  392 

$  393 

$  394 

$  395 

$  396 

$  397 

£ 

393 

$  393 

$ 

6r264 

Operations 

£ 

$ 

£ 

- 

$  - 

$  298 

$  299 

$  300 

5  301 

£  302 

£  303 

$  304 

£  305 

$  306 

$  307 

$  308 

$  309 

£  310 

£  140 

$ 

100 

£  - 

4r192 

Maintenance 

£ 

£ 

$ 

- 

$  - 

£  - 

£  55 

£  55 

$  56 

£  56 

£  57 

$  57 

£  53 

$  58 

$  59 

£  59 

$  60 

£  60 

£  35 

$ 

15 

£  - 

£  737 

Disposal 

£ 

$ 

$ 

- 

£  - 

$  - 

£  - 

$  - 

5  - 

£  - 

£  - 

£  - 

£  - 

$  - 

$  - 

$  - 

$  - 

s  - 

£  - 

$ 

7 

S  12 

$ 

19 
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Table  34.  Spreadsheet  used  to  Normalize  FY11  Costs 


Item 

Acquisition  $  M  or 
K/unit 

O&S  $  M  or  K 

/unit 

O&S  6  sys/yr 

$M 

LCC  6  sys 

$M 

Inflation  Scale 

LCS  Ship2 

FY10 

680.00 

43.00 

258.00 

3870.00 

Inflation  Rate 

FY11 

689.52 

43.60 

261.61 

3924.18 

1.4 

UAV’s1 

FY06 

7.00 

3.94 

47.30 

793.56 

Inflation  Rate 

FY07 

7.19 

4.05 

48.58 

814.99 

2.7 

FY08 

7.36 

4.15 

49.75 

834.55 

2.4 

FY09 

7.47 

4.21 

50.49 

847.06 

1.5 

FY10 

7.55 

4.25 

50.99 

855.45 

0.99 

FY11 

7.65 

4.31 

51.71 

867.43 

1.4 

SH-603 

FY04 

42.42 

28.00 

336.00 

5040.00 

Inflation  Rate 

FY05 

43.60 

28.78 

345.41 

5181.12 

2.8 

FY06 

44.96 

29.68 

356.12 

5341.73 

3.1 

FY07 

46.17 

30.48 

365.73 

5485.96 

2.7 

FY08 

47.28 

31.21 

374.51 

5617.62 

2.4 

FY09 

47.99 

31.68 

380.13 

5701.89 

1.5 

FY10 

48.46 

31.99 

383.89 

5758.34 

0.99 

FY11 

49.14 

32.44 

389.26 

5838.95 

1.4 

The 


above  table  was  used  to  properly 


apply  the  2010  inflation  rates 


to 


system 


elements  to  normalize  the  FY 1 1  pricing. 
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Table  35.  Spreadsheet  1  used  to  Estimate  CTF-151  Costs. 


Ship 

cost  per 
Ship  ($B) 

total 

acquisiti  on 
cost  ($B) 

added 

item 

(RHIB, 

UAV, 

Helo)  ($B) 

total  added 
cost  ($B) 

LCCfrom 

acquisition 

factor 

LCC  2010 

LCC  2011 
($M) 

Qtv 

TOC($M} 

DDG-51 

$1.5050 

$1.5050 

$0.0882 

$1,593 

1.94 

$3,042 

$3,085 

1 

$3,084.59 

FFG-7 

$0.6710 

$1.3420 

$0.0008 

$1,343 

1.13 

$1,500 

$1,521 

2 

$3,042.00 

LPD- 17# 

$1.2050 

$1.2050 

$0.0002 

$1,205 

1.37 

$1,649 

1 

$1649.44 

Jianwei 

$0.1540 

$0.3080 

'$0.0008 

$0,309 

1.13 

$349 

2 

$697.00 

Ulsan 

$0.1190 

$0.1190 

$0.0002 

$0,119 

1.13 

$135 

1 

$134.70 

Barba ros 

$1.0140 

$3.0420 

$0.0272 

$3,069 

1.94 

$1,967 

3 

$5,901.48 

La  Fayette 

$0.3100 

$0.6200 

$0.0178 

$0,638 

1.13 

$711 

2 

$1421.31 

Iroquois 

$1.1590 

$1.1590 

$0.0119 

$1,171 

1.13 

$1,323 

1 

$1323.12 

Floreal 

$0.1860 

$0.1860 

$0.0122 

$0,198 

1.13 

$224 

1 

$223.97 

Totals 

$6.32 

$9.49 

$0.16 

$9.65 

$12.03 

$4,542.00 

$10,963.13 

14 

$17,477.61 

LCC  Grand  Total 

$17,477.61 
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Table  36.  Spreadsheet  2  Used  to  Estimate  CTF-151  Costs. 


ship 

Quantity  RHIB  Boats 

Cost  RHIB  ($M)  Helicopter  Cost  Helicopter  ($M) 

UAV  System  Cost  UAV  System  ($M)  Total  Cost  ($M) 

DDG-51 

1 

2 

$0,100 

2 

$42.40 

1 

$3.20 

$88.20 

FFG-7 

2 

4 

$0,100 

$0.80 

LPD-17 

1 

2 

$0,100 

$0.20 

jianwei 

2 

4 

$0,100 

$0.80 

lllsan 

1 

2 

$0,100 

$0.20 

Barbaras 

3 

6 

$0,100 

2 

$42.40 

$256.20 

La  Fayette 

2 

4 

$0,100 

2 

$42.40 

$170.00 

Iroquois 

1 

2 

$0,100 

2 

$42.40 

1 

$3.20 

$88.20 

Floreal 

1 

2 

$0,100 

1 

$12* 

$12.20 
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APPENDIX  G  HEAVY  UAV  WEIGHT  VALUE  FUNCTIONS 


System  specifications  provide  information  needed  to  determine  requirements  and 
constraints  for  modules  on  each  alternative  for  storage  and  handling  purposes.  This  will 
help  stakeholders  determine  which  alternative  module  is  most  suitable  for  their  needs. 
Specifications  for  each  system  include  the  weight  (in  pounds),  and  flight  endurance  (in 
hours).  Research  of  system  documentation  was  the  most  widely  used  method  of 
determining  the  specifications.  Confirmed  system  specifications,  as  well  as  best  effort 
estimates,  provided  inputs  to  the  OARS  mission. 

Specifications  for  each  element  reviewed  using  a  value  model  can  be  found  in 
Appendix  G,  Heavy  UAV  Weight  Value  Functions.  An  example  value  model  for  the 
UAV  is  shown  in  Figure  61.  The  attributes  of  this  element  were  broken  down  into  the 
following:  Weight,  Speed,  Range,  Endurance,  Payload,  and  Maximum  Altitude  (height). 


|  UAV  Alternatives  &  Preference  Model  j 

Attribute  Data 

Alternatives 

Weight 

(lbs) 

Max 

I  Speed 
(kt) 

Max 

Range 

(nm) 

Flight 

Duration 

(hrs) 

Payload 

(k8) 

Max  Height 
(m) 

Silver  Fox 

30 

55 

20 

10.00 

3.60 

3650 

Manta  B 

61 

75 

40 

8.00 

6.80 

4870 

Scaneagle 

40 

50 

80 

15.00 

6.00 

5000 

Exdrone 

6S 

87 

80 

2.50 

113 

4000 

|  Standardize  al  Attributes  into  a  Single  Scale. 

Attribute  Data  in  Value  Scale 

Silver  Fox 

1.000 

0.150 

0.000 

0.580 

0.000 

0.000 

Manta  B 

0.130 

0.680 

0.750 

0.420 

0.160 

0.840 

Scaneagle 

0.720 

0.000 

1.000 

1.000 

0.100 

1.000 

Exdrone 

0.000 

1.000 

1.000 

0.000 

1.000 

0290 

Attribute  Contribution  to  Overall 

Value  Measure 

Silver  Fox 

O.OSO 

0.030 

0.000 

0.145 

0000 

0.000 

Manta  B 

0.007 

0.136 

0188 

0.105 

0.016 

0.126 

Scaneagle 

0036 

0.000 

0.250 

0.250 

0.010 

0.150 

Exdrone 

0.000 

0.200 

0250 

0.000 

0.100 

0.044 

Value  Scale  versus  Attribute  Scale 


Effective  Weight  Value  Function 


Attribute  with  Respective  Weights 


Attribute^  Weight(wU  .  .  .  .  .  ,  .  .  , 

0  05  Multiply  weights  times  values 
found  for  each  function  to 


Weight 

Speed 

Range 

Duration 

Payload 

Height 


0.20 

0.25 

0.25 

0.10 

0.15 


Total 


1.00 


obtain  the  overall  value 
measure  of  attribute 
contribution  for  each 
alternative 


y(Xj)  =  w,*v,(xu)+  +  *v„(xBJ) 


Figure  61.  Alternative  Match-Up  of  Life  Cycle  Costs. 
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Table  37  details  the  total  measured  value  and  the  costs  for  each  of  the  UAV 
elements  under  consideration.  In  order  for  decision  makers  to  understand  the  raw  data 
better,  these  data  points  were  graphed  in  Figure  62  below. 


Table  37.  Lightweight  UAV  Costs  versus  Measure  of  Value. 


Light-WeighUJAV 


Cost$K 

Value  Measure  Total 

Silver  Fox 

50 

0.225 

Mlanta  B 

40.5 

0.577 

Scaneagle 

120 

0.696 

Exdrone 

110 

0.5935 

Efficiency  Frontier 


Cost  of  Light-Weight  UAV  $K 


Figure  62.  Alternative  Match-Up  of  Life  Cycle  Costs. 
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The  ScanEagle  and  Manta  B  UAVs  were  on  the  efficiency  frontier  in  Figure  62. 
The  data  shows  that  the  ScanEagle  was  the  preferred  choice  between  the  two,  due  mostly 
to  the  preferred  elevated  endurance  of  the  ScanEagle.  The  value  preference  model  data 
and  the  corresponding  characteristic  attributes  were  exactly  the  same  as  the  light  UAVs 
as  seen  in  Figure  61. 

Table  38.  Lightweight  UAV  Costs  versus  Measure  of  Value. 

Attribute  Co ntri button  to  0 ve ra II  Vai ue  Measure  T ota h 


Alternatives 

Silver  Fok 

Weight 

0,050 

Speed 

0.030 

Range 

0.000 

Endurance 

0.145 

Payload 

0.000 

Height 

0.000 

0.225 

Manta  8 

0,007 

0.136 

0,138 

0.105 

0,016 

0.126 

0.577 

Scaneagle 

0.036 

0.000 

0.250 

0.250 

0.010 

0.150 

0.696 

Exdrone 

0,000 

0,200 

0,250 

0,000 

0,100 

0,044 

0,594 

The  Heavy  UAV  comparison  of  cost  and  value  totals  is  shown  in  Table  39  below. 
The  data  applied  to  a  graphic  presentation  can  be  found  below  in  Figure  63.  The  data 
shows  that  two  UAV  systems  appear  in  the  efficiency  frontier.  The  UAV  system  that 
stands  out  as  the  dominate  system  is  the  MQ-4C,  which  is  located  on  the  upper  left 
quadrant.  The  Euro  Hawk  is  slightly  more  expensive  due  mainly  to  the  addition  of  export 
requirements  that  would  be  necessary  for  a  European  military  market. 


Table  39.  Heavy  UAV  Costs  versus  Measure  of  Value. 


Heavy  UAV 

Cost  $M 

Value  Measure 

Total 

MQ-4C-BAMS 

210 

0.3305 

Global  Hawk 

220 

0.73 

Euro  Hawk 

221 

0.869 

Mariner  (Predator  B,  BAMS) 

N/A 

N/A 
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Cost  of  Heavy-Weight  UAV  $M 


Figure  63.  Heavy  UAV  Costs  versus  Preference  Value  Total. 


The  final  selection  of  elements  to  the  OARS  system  was  with  regard  to  the  RHIB 
pursuit  vessels.  Appendix  F  contains  the  Value  Functions  for  each  attribute,  which  are: 
Payload,  Speed,  Range,  Length,  Weight,  and  Beam.  These  attributes  make  up  the 
respective  column  headings  in  Table  40.  Table  41  below  matches  the  value  totals  with 
costs  per  RHIB. 

Table  40.  RHIB  attribute  Contribution  to  overall  Value  Measure. 


Attribute  Contribution  to  Overall  Value  Measure  Totals 


RHIB 

Length 

Beam 

Weight 

Speed 

Payload 

Range 

USMI 

0.010 

0.01S 

0.013 

0.020 

0.005 

0.285 

0.351 

Willard  Marine,  ino* 

0.010 

0.000 

0.000 

0.000 

0.200 

0.000 

C.210 

ASIS 

0.000 

0.100 

0.050 

0.073 

0.000 

0.195 

0.41S 

Zodiac  Midline  3 

0.100 

0.025 

0.02S 

0.250 

0.024 

0.300 

0.727 
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Table  41.  RHIB  attribute  Contribution  to  overall  Value  Measure. 


RHIB 

Cost  $  K 

Value  Measure 

Total 

USMI 

456.589 

0.35 

Willard  Marine,  Inc. 

107.177 

0.21 

ASIS 

94 

0.42 

Zodiac  Midline  3 

71.417 

0.73 

Figure  64  below  presents  the  RHIB  data  via  a  graph  and  helps  to  explain  the 
choices  remaining  for  the  RHIB  selection  process.  The  dominated  region  in  the  lower 
portion  of  the  graph  shows  the  elements  that  would  not  be  preferred.  The  remaining 
system,  the  Zodiac,  is  above  the  “dominated  region”  due  to  its  preferred  characteristics. 
According  to  Figure  64,  the  Zodiac  appears  to  be  the  clear  winner. 


Dominated  Region 


Cost  of  RHIB  UAV  $K 


Figure  64.  Heavy  UAV  Cost  versus  Preference  Value  Total. 
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Heavy  Weight  UAVs  j  Atribute  Data  1 


Aternatves 

Max  Gross  "ake 
off  We  ght 

Range 

Payload  Capacity 
nterior/exter  or 

Max 

Altitude 

Max 

Endurance 

Max  Air 

Speed 

fcs 

nm 

lbs 

ft 

hrs 

knt 

MQ-AC-3AMS 

32250 

8200 

560C 

56500 

28 

351 

G  cba  Hawk 

2670C 

11C0C 

29CO 

65000  31 

343 

Euro  Hawk 

2560C 

12000 

2000 

65000 

35 

343 

Mariner  (Prede 

10500 

10000 

3850 

50000 

30 

240 

Attribute  Data  in  Value  Scale 

MQ-4C-3AMS 

0.00 

0.00 

1.00 

0.35 

0.00 

0.89 

G  oba  Hawk 

C.32 

0.98 

0.24 

1.00 

0.44 

1  00 

Euro  Hawk 

C  38 

1  00 

D  DO 

1.00 

1.0C 

1.00 

Attribute 

Weight 

Mariner  (Prede 

1.00 

C.9C 

0.51 

0.00 

0.26 

0.00 

Weght 

0.05 

Speed 

0.20 

Attribute  Contribution  to  Overall  Value  Measure 

Totals 

Range 

0.25 

MQ-4C-3AMS 

0.00 

0.00 

0.10 

0.05 

0.00 

0.18 

0.331 

Durat  cn 

0.25 

G  oba  Hawk 

0.02 

0.25 

0.02 

C.15 

0.11 

0.20 

0.745 

Payload 

0.10 

Euro  Hawk 

0.02 

0.25 

0.00 

0.15 

0.25 

0.20 

0869 

Height 

0.15 

Marmer  (Prede 

0.05 

C.23 

0.05 

0.00 

0.07 

0.00 

0.391 
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Payload  Value  Function 


Range  Value  Function 


0  2000  4000  6000  0000  10000  12000 
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Height  Value  Function 
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APPENDIX  H  RHIB  WEIGHT  VALUE  FUNCTIONS 


RHIBS 

Atribute  Oata 

Manufacturer 

Length 

Beam  (m) 

Weight  (lbs) 

Speed  (kts)  Payload(lbs 

Range  (nm) 

Capacity 

USMI 

11.00 

3.20 

17,400 

46.00 

3200 

200nm 

13.00 

Willard  Marine,  Inc. 

11.00 

3.70 

22,000 

45.00 

18000 

llOnm 

26.00 

ASIS 

9.80 

3.10 

3190 

48.00 

3000 

127nm 

21.00 

Zodiac  Midline  3 

11.12 

3.23 

11155 

57.00 

4850 

210nm 

10.00 

Attribute  Data  in  Value  Scale 

USMI 

0.820 

0.180 

0.250 

0.080 

0.025 

0.990 

0.200 

Willard  Marine,  Inc. 

0.820 

0.000 

0.000 

0.000 

1.000 

0.000 

1.000 

Attribute 

Weight 

ASIS 

0.000 

1.000 

1.000 

0.250 

0.000 

0.550 

0.700 

Weight 

0.150 

Zodiac  Midline  3 

1.000 

0.250 

0.580 

1.000 

0.120 

1.000 

0.000 

Speed 

0.200 

Range 

0.250 

Attribute  Contribution  to  Overall  Value 

Measure 

Totals 

Beam 

0.050 

USMI 

0.041 

0.009 

0.038 

0.020 

0.005 

0.248 

0.020 

0.360 

Payload 

0.200 

Willard  Marine,  Inc. 

0.041 

0.000 

0.000 

0.000 

0.200 

0.000 

0.100 

0.241 

Length 

0.050 

ASIS 

0.000 

0.050 

0.150 

0.063 

0.000 

0.138 

0.070 

0.400 

Capacity 

0.100 

Zodiac  Midline  3 

0.050 

0.013 

0.087 

0.250 

0.024 

0.250 

0.000 

0.674 
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Weight  Value  Function 
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APPENDIX  I  LCC  OF  THE  OARS  ALTERNATIVES  BROKEN 
DOWN  BY  FUNCTIONAL  OBJECTIVES 


Each  OARS  alternative  will  procure  systems  according  to  the  assessment  made  in 
the  Recommended  Alternatives  section.  Costs  are  displayed  in  four  functional  objective 
areas.  Those  areas  are: 

•  Detection  in  patrol. 

•  Command,  control  &  communicate. 

•  Localize  and  track. 

•  Engage. 

Due  to  some  similarities  between  the  two  OARS  alternatives,  each  of  them  will 
tally  similar  costs  in  the  “Detection  in  Patrol”  category.  This  is  due  to  the  fact  that  both 
alternatives  utilize  similar  modem  UAV  sensor  packages.  Contrastingly,  the  two 
alternatives  have  some  costs  that  vary  distinctly  due  to  the  fact  that  the  augmented  OARS 
alternative  utilizes  a  Broad  Area  Maritime  Surveillance  (BAMS)  system,  whereas  the 
Basic  OARS  system  does  not. 

A.  ALTERNATIVE  #1,  OARS  BASIC 

The  cost  of  the  primary  search  sensor,  the  UAV  system,  is  roughly  13  times 
cheaper  than  all  other  detection  system  costs  combined  for  Alternative  1 .  Procurement 
costs  of  the  UAV  systems  are  quite  small  compared  to  the  overall  procurement  cost.  The 
costs  associated  with  procuring  surface  sensors  are  identical  between  both  alternatives. 
All  LCS  platforms  have  the  same  radar,  EADS-Air  search,  and  Sea  Giraffe-surface 
search  capabilities,  thus  they  all  have  the  same  costs. 

Figure  65  shows  the  LCC  of  Alternative  1  broken  out  by  functional  objectives. 
The  bulk  of  the  costs  center  around  the  LCS  host  ship  system  and  since  Alternative  1 
utilizes  six  host  ships,  this  cost  is  very  large. 


173 


Alternative  1  LCC  by  Functional 
Objective 

£  Detection 

■  C-3 

■  Localization  and 
Tracking 

■  Engagement 


Figure  65.  Alternative  1  LCC  by  Functional  Objective. 

B.  ALTERNATIVE  #2,  OARS  AUGMENTED 

Procurement  costs  for  Alternative  2  also  consist  of  each  of  the  four  functional 
objectives.  Figure  66  shows  that  this  alternative  allows  the  funding  for  surface  sensors  to 
grow  in  parity  to  the  remaining  three  functional  objectives.  Due  to  the  Alternative  2"s 
addition  of  an  air-borne  surface  sensor,  the  total  procurement  costs  are  increased,  thus 
making  this  the  more  expensive  alternative. 

Airborne  surface  sensors  remained  the  largest  functional  objective  with  27%  of 
the  total  costs.  Airborne  surface  sensor  costs  are  split  between  the  SH-60  Helicopter  and 
the  UAVs,  but  the  primary  sensor  is  the  UAV.  Distribution  of  the  remaining  costs  will 
weigh  heavily  on  combat  systems  at  29%. 
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Alternative  2  LCC  by  Functional 
Objective 


■  Detection 


■  C-3 

■  Localization  and 
Tracking 

■  Engagement 


Figure  66.  Alternative  2  LCC  by  Functional  Objective. 


The  total  funding  amount  is  largely  affected  by  the  procurement  cost  of  the  host 
ship  platforms.  However,  the  addition  of  Alternative  2"s  BAMS  system  increases  the 
procurement  cost  within  the  surface  detection  functional  objective  from  15%  in 
Alternative  1  to  27%  in  Alternative  2.  The  Zodiac  Rigid  Hull  Inflatable  Boats  (RHIB), 
which  are  utilized  as  pursuit  vessels  in  both  alternatives,  represent  the  lowest 
procurement  cost  items  in  each  of  the  alternatives  at  $0,852  Million.  The  .50  caliber 
machine  guns  represent  roughly  $2,032  Million  of  material  that  will  be  affixed  and 
deployed  on  the  RHIB  boats.  The  RHIB  gun  element  was  priced  with  one  million  rounds 
in  procurement.  In  contrast  to  the  surface  engagement  RHIB  boats,  the  primary  airborne 
engagement  element  of  the  OARS  system,  the  SH-60  Sea  Hawk  Helicopter,  will  assume 
roughly  16%  of  the  procurement  costs. 

The  introduction  of  the  BAMS  system  accounts  for  18%  of  the  LCC  at  almost 
$3.2  billion.  The  preference  model  in  Appendix  G  dictated  the  use  of  the  Global  Hawk 
or  Euro  Hawk  BAMS  vehicle  from  a  superior  flight  endurance  point  of  view. 
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LCC  versus  FO  Comparison 


Functional  Objectives 


■  OARS  AUGMENTED 

■  OARS  BASIC 


Figure  67.  LCC  versus  Functional  Objective  Comparison. 


Figure  67  and  Table  42  illustrate  a  comparison  of  both  OARS  alternatives”  Life 
Cycle  Costs  broken  out  by  their  functional  objectives.  As  mentioned  above,  the  OARS 
Augmented  option  was  the  most  expensive  option. 


Table  42.  LCC  by  Functional  Objective  Comparison. 


Life-Cycle  Cost  by 
Function 

Detection 

C-3 

Localization  and 
Tracking 

Engagement 

Total 

OARS  BASIC 

$  2320  Million 

$4484.6 

Million 

$4175.3  Million 

$4484.6  Million 

$15465  Million 

OARS 

AUGMENTED 

$  4783  Million 

$4439  Million 

$4110  Million 

$4438.5  Million 

$  17770.5 
Million 
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